Repository navigation
[BUG] Three tests in test_console.py are shadowed or unasserted, hiding two stale expectations #4224
Description
- I've checked docs and closed issues for possible solutions.
- I can't find my issue in the FAQ.
Describe the bug
Three tests in tests/test_console.py don't run, or don't assert anything. Two of them are hiding assertions that no longer match Rich's current behaviour, so this isn't only a tidy-up — restoring them surfaces two stale expectations.
Checked against master (9d8f9a37), Python 3.12, macOS.
1. test_soft_wrap is defined twice (lines 48 and 604)
The second definition wins and the first never runs. They are different tests:
# line 48 -- never collected
def test_soft_wrap() -> None:
console = Console(file=io.StringIO(), width=20, soft_wrap=True)
console.print("foo " * 10)
assert console.file.getvalue() == "foo " * 20
# line 604 -- this is the one that runs
def test_soft_wrap() -> None:
console = Console(width=10, file=io.StringIO())
console.print("foo bar baz egg", soft_wrap=True)
assert console.file.getvalue() == "foo bar baz egg\n"Renaming the first one to run it makes it fail: it expects "foo " * 20 (the input duplicated) with no trailing newline, but Rich emits "foo " * 10 plus \n. The expectation looks wrong rather than the code — the second test asserts the same "soft wrap doesn't wrap, and ends with a newline" behaviour and passes. So the shadowed copy appears to be an obsolete leftover.
2. test_force_color is defined twice (lines 953 and 968) — this one loses parametrization
# line 953 -- never collected, and it's parametrized
@pytest.mark.parametrize("env_value", ["", "something", "0"])
def test_force_color(env_value) -> None:
console = Console(file=io.StringIO(), _environ={"FORCE_COLOR": env_value})
assert console.is_terminal
# line 968 -- this is the one that runs
def test_force_color() -> None:
...
assert console.color_system in ("truecolor", "windows")pytest --collect-only currently shows one test_force_color; it should be three parametrized cases plus the unparametrized one.
Restoring the parametrized version fails on env_value="", and that one is legitimately obsolete: it dates from #2467 (2022), while 9175392a ("New environment var", 2025-03-28) deliberately changed is_terminal to
force_color = environ.get("FORCE_COLOR")
if force_color is not None:
return force_color != ""so an empty FORCE_COLOR is now explicitly not a terminal, per https://force-color.org/. The shadowing is why CI never flagged the contradiction. The "something" and "0" cases still pass and are worth keeping.
3. test_tty_interactive builds a Console and never asserts on it (line 1063)
# Force tty compatible, force not interactive
console = Console(
file=io.BytesIO(), _environ={"TTY_COMPATIBLE": "1", "TTY_INTERACTIVE": "0"}
)
# Bytes file, Unknown value of TTY_INTERACTIVE should still auto-detect
console = Console(file=io.BytesIO(), _environ={"TTY_INTERACTIVE": "foo"})
assert not console.is_interactiveThe first console is overwritten before use, so the TTY_COMPATIBLE=1 + TTY_INTERACTIVE=0 case — the interesting one, where the two vars disagree — is never checked. The behaviour is correct today (is_interactive is False); the assertion is just missing.
Proposed fix
Happy to open a PR that:
- deletes the obsolete shadowed
test_soft_wrap(line 48); - restores the parametrized
test_force_colorunder a distinct name, dropping the now-invalid""case and keeping"something"/"0", and renames the other to reflect what it checks (color_system, notis_terminal); - adds the missing
assert not console.is_interactiveintest_tty_interactive.
Point 2 is the one worth a maintainer opinion before I write it: I've assumed the 2025 FORCE_COLOR="" change is intended and the old test is stale, but tell me if you'd rather keep the old assertion and treat it as a regression.
Platform
macOS, Python 3.12, rich at 9d8f9a37 (version 15.0.0).
Click to expand
Found with a small AST script that flags duplicate top-level definitions and values that are overwritten before use. Per AI_POLICY.md: this report was prepared with AI assistance (Claude); every claim above was verified by running the tests locally.
Activity
EngineeringWithJay commentedon Oct 17, 2026
I reproduced these findings on
mainat9d8f9a372cc5916fd4781fec207ced7ddac2f08f(macOS, Python 3.12.13). The original file passes 100 tests; restoring the shadowed
definitions exposes the two reported failures among 104 tests.
I have a local, test-only patch that:
original input plus a trailing newline as its expectation.
"" → False,"something" → True, and"0" → Trueforis_terminal.TTY_COMPATIBLE=1withTTY_INTERACTIVE=0.All 104 tests in
tests/test_console.pypass in two runs, as do the eight focusedcases. No production code changes are proposed. Unlike the issue's delete/drop
proposal, this retains both the constructor test and the empty-string case.
This work is AI-assisted: the proposed patch and this draft were AI-generated
using Astra Coder (OpenAI GPT-6 Astra, via OpenCode), with local test verification.
Would @willmcgugan approve proceeding with a PR on this basis, including the
current empty-FORCE_COLOR behavior, or prefer the narrower approach in the issue?
I will wait for maintainer approval before opening a PR and, if approved, fill in
the PR template, disclose the agent, and link the approval discussion as required
by the AI policy.