Problem
__tests__/e2e/ holds seven jest suites that no CI job runs.
browse-provider-flow.test.tsx
browse-session-nav-race.test.tsx
diagnostics-flow.test.tsx
feedback-flow.test.tsx
onboarding-flow.test.tsx
session-new-start.test.tsx
settings-flow.test.tsx
package.json defines "test:e2e": "jest --ci --testPathPattern='__tests__/e2e'", and nothing in .github/ invokes it.
The five jest invocations across both workflow files are test:unit, test:scripts, test:integration, test:i18n, and test:e2e:mock (Maestro, schedule-only).
At least one of them is already failing.
onboarding-flow.test.tsx › shows localhost-specific warning when URL contains localhost fails on a clean checkout, run alone, deterministically — the tree renders fully and the element is simply absent, so it is not a timeout under load.
Nobody noticed because nothing runs it.
The discriminator
The question is not whether a script exists but whether any workflow invokes it. "It's in __tests__/" is not wiring.
These files look wired in every way that matters to a reader: they sit alongside __tests__/unit and __tests__/integration, they are written in the same style, they have an npm script, and they pass or fail when run by hand.
None of that is CI running them.
Confirmed from a CI log, not from config
Reading this off a jest project's testPathPattern is not sufficient — a config glob can wire a directory in implicitly, with no workflow ever naming the script.
That is the mirror-image failure, and it is live in the streamer repo today: its vitest include glob runs its contracts/ and e2e/ files without any workflow naming them.
The two repos have opposite answers, so this had to be confirmed empirically.
Counting the actual PASS/FAIL lines from a green main CI run:
| directory |
files executed |
__tests__/unit |
110 |
__tests__/integration |
41 |
__tests__/i18n* |
3 |
__tests__/e2e |
0 |
Relation to #519
Structurally identical, different family.
#519 was seven Maestro flows nothing runs; this is seven jest suites nothing runs.
Two independent test families in one repo, both looking wired because of where they sit.
The Maestro case at least has a stated reason — E2E maestro (iOS) is deliberately schedule-only because macOS runners are expensive.
There is no such reason here: these are ordinary jest suites that would cost seconds in the existing Unit/Integration jobs.
What to decide
Wire them in or delete them; the current state is the one option with no value.
If wiring them in, expect the first run to be red — onboarding-flow is already failing and the others have had the same freedom to rot.
That makes this two pieces of work: add the job, then fix whatever it surfaces.
Doing it in that order is fine and probably correct, but it should be a deliberate choice rather than a surprise.
Note that session-new-start.test.tsx was edited as recently as #533 and that edit was never CI-verified.
Whether onboarding-flow's assertion is stale or the warning genuinely regressed is a separate question, and deliberately not answered here — a test nothing runs cannot tell you which, which is the point.
Found while doing #519 and #533.
Problem
__tests__/e2e/holds seven jest suites that no CI job runs.package.jsondefines"test:e2e": "jest --ci --testPathPattern='__tests__/e2e'", and nothing in.github/invokes it.The five jest invocations across both workflow files are
test:unit,test:scripts,test:integration,test:i18n, andtest:e2e:mock(Maestro, schedule-only).At least one of them is already failing.
onboarding-flow.test.tsx › shows localhost-specific warning when URL contains localhostfails on a clean checkout, run alone, deterministically — the tree renders fully and the element is simply absent, so it is not a timeout under load.Nobody noticed because nothing runs it.
The discriminator
The question is not whether a script exists but whether any workflow invokes it. "It's in
__tests__/" is not wiring.These files look wired in every way that matters to a reader: they sit alongside
__tests__/unitand__tests__/integration, they are written in the same style, they have an npm script, and they pass or fail when run by hand.None of that is CI running them.
Confirmed from a CI log, not from config
Reading this off a jest project's
testPathPatternis not sufficient — a config glob can wire a directory in implicitly, with no workflow ever naming the script.That is the mirror-image failure, and it is live in the streamer repo today: its vitest
includeglob runs itscontracts/ande2e/files without any workflow naming them.The two repos have opposite answers, so this had to be confirmed empirically.
Counting the actual
PASS/FAILlines from a greenmainCI run:__tests__/unit__tests__/integration__tests__/i18n*__tests__/e2eRelation to #519
Structurally identical, different family.
#519 was seven Maestro flows nothing runs; this is seven jest suites nothing runs.
Two independent test families in one repo, both looking wired because of where they sit.
The Maestro case at least has a stated reason —
E2E maestro (iOS)is deliberately schedule-only because macOS runners are expensive.There is no such reason here: these are ordinary jest suites that would cost seconds in the existing Unit/Integration jobs.
What to decide
Wire them in or delete them; the current state is the one option with no value.
If wiring them in, expect the first run to be red —
onboarding-flowis already failing and the others have had the same freedom to rot.That makes this two pieces of work: add the job, then fix whatever it surfaces.
Doing it in that order is fine and probably correct, but it should be a deliberate choice rather than a surprise.
Note that
session-new-start.test.tsxwas edited as recently as #533 and that edit was never CI-verified.Whether
onboarding-flow's assertion is stale or the warning genuinely regressed is a separate question, and deliberately not answered here — a test nothing runs cannot tell you which, which is the point.Found while doing #519 and #533.