[BUG] Three tests in test_console.py are shadowed or unasserted, hiding two stale expectations

#4224 · open · 0 comments

View on GitHub ↗

mathewOracle

- [x] I've checked [docs](https://rich.readthedocs.io/en/latest/introduction.html) and [closed issues](https://github.com/Textualize/rich/issues?q=is%3Aissue+is%3Aclosed) for possible solutions. - [x] I can't find my issue in the [FAQ](https://github.com/Textualize/rich/blob/master/FAQ.md). **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: ```python # 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** ```python # 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 ```python 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)** ```python # 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_interactive ``` The 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: 1. deletes the obsolete shadowed `test_soft_wrap` (line 48); 2. restores the parametrized `test_force_color` under a distinct name, dropping the now-invalid `""` case and keeping `"something"`/`"0"`, and renames the other to reflect what it checks (`color_system`, not `is_terminal`); 3. adds the missing `assert not console.is_interactive` in `test_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). <details> <summary>Click to expand</summary> Found with a small AST script that flags duplicate top-level definitions and values that are overwritten before use. Per [AI_POLICY.md](https://github.com/Textualize/rich/blob/master/AI_POLICY.md): this report was prepared with AI assistance (Claude); every claim above was verified by running the tests locally. </details>

Comments