fix(tui): isolate lifecycle and theme tests - #41310
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Stabilizes the seven TUI tests that failed on both Linux and Windows when v2 branch CI was enabled: four app lifecycle tests and three invalid-theme fallback variants.
Before / After
Before: lifecycle tests installed a process-global Bun module mock for
@opentui/coreafter creating a test renderer. Test files can import the same module concurrently, so CI could retain the unmockedcreateCliRenderer; the SIGHUP test then timed out with a real renderer owning stdin, and the next lifecycle tests cascaded withstdin is already used by another CliRenderer. This pattern originated in106f8e94d67.After: lifecycle tests use the app's existing
terminalHandoffinput to supply their renderer directly. No module cache or global mock ordering is involved, and scoped cleanup releases the exact renderer owned by each test.Before: the invalid-theme tests used an already-resolved discovery promise. Theme discovery could emit its error before the child probe's
onErrorsubscription was installed, leavingfailureundefined on faster CI runners. This race originated with the fallback tests in8f3465c951aand remained after the hook split in08b80da9310.After: discovery is held behind a test-owned promise and released after the renderer and probe are mounted, so each fallback assertion observes the intended error.
How
packages/tui/test/app-lifecycle.test.tsxreplaces fourmock.modulesetups withterminalHandoff.packages/tui/test/cli/tui/theme-mode.test.tsxexplicitly sequences invalid-theme discovery after subscription setup.Scope
This PR does not change runtime TUI behavior. The independent core session-runner cassette and plugin flush failures are handled separately.
Testing
cd packages/tui && bun typecheckpasses.cd packages/tui && bun run test test/app-lifecycle.test.tsx test/cli/tui/theme-mode.test.tsxpasses three consecutive runs: 9 tests each, 0 failures.cd packages/tui && bun run testpasses: 607 passed, 5 skipped, 0 failed across 97 files.