Repository navigation
test(daemon): remove daemon pins that cannot fire - #2942
Merged
Merged
Conversation
Four daemon tests asserted things no production change could contradict.
- `session-relaunch-guards.test.ts`: "…for active sessions before device refresh" was
byte-identical to the test above it (`diff` empty). Its ordering claim is not
observable through any mock in this harness — on the existing-session path the refresh
is `refreshSessionDeviceIfNeeded`, which returns early for a non-iOS device — so the
test only re-asserted the message. Deleted.
- `session-relaunch-guards.test.ts`: "…before resolving a new device" was byte-identical
to the first binary-path test, but its name promises something real and fixable: the
pre-resolved guard at `session-open.ts:262` runs before `resolveTargetDeviceSelection`
at :269. It now asserts `mockResolveTargetDevice` was not called, which makes the name
true. Proven: hoisting the selection above the guard while leaving the messages
untouched fails exactly this test (`1 failed | 7 passed`) — every sibling stays green
because they only read the message.
- `response-views.test.ts`: three `typeof x === 'function'` tests, each immediately
followed by a test that calls that same view and asserts its digest — the `!` is erased
at runtime, so an unregistered view throws there first. Entailment is exact. The five
matching `typeof` lines inside the shared-view tests go too; the `findView === getView`
and `press === click === fill === longpress` identity pins stay, since splitting a
shared view really does redden those.
- `providers-plugin-routing-parity.test.ts`: `assert.equal(getPlugin('apple'),
getPlugin('apple'))` compares one `Map.get` call to itself, and its comment claimed an
ios/macos alias the collapsed `PLATFORMS` union no longer has. The exact-array
assertions in that block are kept — they are the only thing that catches a facet
listing a resolver twice, which the membership scan above cannot see.
- `interaction-response-construction-guard.test.ts`: a positive control run over a
file-local fixture with no production file in scope. The ADR 0011 guard's real positive
control scans the actual dispatcher; and the fixture case is already entailed by the
negative controls, each of which mutates one case and asserts a one-element violation
array, proving every other case contributes nothing.
Contributor
Size Report
Startup median (7 runs, lower is better):
|
Member
Author
|
Reviewed at 07ef103. The removed assertions are ones that cannot fire, so dropping them is correct; the mechanism checks out, since |
thymikee
added
the
ready-for-human
Contributor
|
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
1 participant
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.
Summary
Five daemon assertions that no production change could contradict. −56 / +4, all test-only, in
four files under
src/daemon.session-relaunch-guards.test.ts— "…for active sessions before device refresh"diffof the two bodies is empty), and its ordering claim is unobservable here: on the existing-session path the refresh isrefreshSessionDeviceIfNeeded, which returns early for a non-iOS devicesession-relaunch-guards.test.ts— "…before resolving a new device"validatePreResolvedOpenRequest(session-open.ts:262) runs beforeresolveTargetDeviceSelection(:269)mockResolveTargetDevicewas not calledresponse-views.test.ts:23,125,574— "X view is registered"typeof x === 'function', and the very next test calls that same view; the!is erased at runtime, so an unregistered view throws there first. Exact entailmentproviders-plugin-routing-parity.test.ts:129assert.equal(getPlugin('apple'), getPlugin('apple'))— oneMap.getcall compared to itself; the comment above it described an ios/macos alias the collapsedPLATFORMSunion no longer hasinteraction-response-construction-guard.test.ts:247:183) scans the actual dispatcherProof for the repair. Hoisting
resolveTargetDeviceSelectionabove the pre-resolved guard whileleaving every message identical fails exactly one test —
1 failed | 7 passed. The message-onlysiblings stay green, because reading the message is all they do. The old body of this test was among
those seven.
Two things I deliberately kept against my own finding list:
findView === getViewandpress === click === fill === longpressidentity pins — splitting ashared view into two instances genuinely reddens those; only the
typeoflines in the same tests goproviders-plugin-routing-parity— the membership scan abovethem cannot see a resolver listed twice, so those arrays are the only duplicate detector
Validation
Tested at
07ef1039f.--project unit-core)git statusclean of production changes before committingpnpm check:affected --run— all runnable checks passedoxlint . --deny-warnings, repo-wideoxfmt,tsc -p tsconfig.jsonNo production file touched, so no device lane is selected.