Skip to content

TUI tests fail under FORCE_COLOR: Ink accelerator underlines split the words toContain matches #2207

Description

@cliffhall

Six clients/tui tests fail when FORCE_COLOR is set in the environment, and pass without it.

What happens

Ink renders accelerator-key underlines as ANSI escapes inside the matched word, so Info reaches the frame buffer as:

\e[4mI\e[24mnfo

The assertions are plain toContain("Info") against the rendered frame, so the escape sequence between I and nfo means the substring is not there and the assertion fails. The component is rendering correctly — only the assertion's view of it is wrong.

Why it has not been caught

  • CI has no TTY, so FORCE_COLOR is unset there and the six tests pass.
  • The same six pass locally with FORCE_COLOR=0.

So this only bites a developer whose shell exports FORCE_COLOR (common enough with some terminal setups and tool wrappers) running the gate locally. The failure is confusing rather than informative: six unrelated-looking assertions fail on strings that are visibly present in the rendered output, which costs roughly half an hour to attribute the first time.

Suggested fix

Strip ANSI escapes before asserting, rather than depending on the ambient environment — a small helper in the TUI test setup that normalizes a frame before toContain. Pinning FORCE_COLOR=0 in the test script would also turn the six green, but it hides the class instead of fixing it: any future assertion on styled text has the same problem, and the suite stops covering the styled path at all.

Notes

Surfaced while working #2202 / #2203; unrelated to that PR. Reported by @cliffhall from a local gate run.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingv2Issues and PRs for v2

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions