test: four DoD items from #150 and #151 remain uncovered after #188 #295

New Issue

clawbot · 2026-08-17T08:08:57+02:00

clawbot commented

2026-08-17 08:08:57 +02:00

#188 scoped itself to four of the definition-of-done items from #150 and #151, and covered all four. Four others were outside that scope and are still unasserted, so closing #188 does not fully close the gap those two issues opened.

Enumerated by the independent review of #288, which confirmed against tests/ that nothing currently touches them.

Still uncovered, from #150:

Add a token by contract address, return to AddressDetail, and see it in the balance list. Nothing in tests/ touches btn-add-token-confirm, so the confirm path — the actual point of the screen — has no browser coverage at all.

Still uncovered, from #151:

Opening TransactionDetail from AddressToken. The equivalent entry from AddressDetail is covered; this second entry point is not.
The etherscan token link on the contract row.
Back from TransactionDetail returning to the originating view. This is the same second-order failure class #188 asserted for AddToken — a wrong stack is invisible on screen until the user presses Back one time too many — and it is unasserted for this screen.

Implementation requirements

Assert against the persisted navigation stack for the Back item, not the visible view. #188 established that pattern for exactly this reason and it should be reused rather than re-invented.
The two entry points into TransactionDetail must be distinguishable: a test that passes when AddressToken silently routes through the AddressDetail path is not coverage of AddressToken.
Demonstrate every new assertion failing. Break the behaviour, capture the output, restore — one deliberate break at a time, with the pre-existing tests staying green so each failure is attributable. That is the standard #288 met and it is what makes these tests worth having.
Check whether the etherscan link assertion can be made without a network call; the harness fails the run on unstubbed requests.

Definition of done

All four items above are asserted in the Chrome e2e suite.
Each new assertion demonstrated failing against a deliberate break, with captured output in the PR body.
No existing test or helper weakened to accommodate them.
TODO.md updated in the same commit.
make check passes.

https://git.eeqj.de/sneak/AutistMask/issues/188 scoped itself to four of the definition-of-done items from https://git.eeqj.de/sneak/AutistMask/issues/150 and https://git.eeqj.de/sneak/AutistMask/issues/151, and covered all four. Four others were outside that scope and are still unasserted, so closing #188 does not fully close the gap those two issues opened. Enumerated by the independent review of https://git.eeqj.de/sneak/AutistMask/pulls/288, which confirmed against `tests/` that nothing currently touches them. Still uncovered, from #150: - Add a token by contract address, return to AddressDetail, and see it in the balance list. Nothing in `tests/` touches `btn-add-token-confirm`, so the confirm path — the actual point of the screen — has no browser coverage at all. Still uncovered, from #151: - Opening TransactionDetail from AddressToken. The equivalent entry from AddressDetail is covered; this second entry point is not. - The etherscan token link on the contract row. - Back from TransactionDetail returning to the originating view. This is the same second-order failure class #188 asserted for AddToken — a wrong stack is invisible on screen until the user presses Back one time too many — and it is unasserted for this screen. ## Implementation requirements - Assert against the persisted navigation stack for the Back item, not the visible view. #188 established that pattern for exactly this reason and it should be reused rather than re-invented. - The two entry points into TransactionDetail must be distinguishable: a test that passes when AddressToken silently routes through the AddressDetail path is not coverage of AddressToken. - Demonstrate every new assertion failing. Break the behaviour, capture the output, restore — one deliberate break at a time, with the pre-existing tests staying green so each failure is attributable. That is the standard https://git.eeqj.de/sneak/AutistMask/pulls/288 met and it is what makes these tests worth having. - Check whether the etherscan link assertion can be made without a network call; the harness fails the run on unstubbed requests. ## Definition of done - [ ] All four items above are asserted in the Chrome e2e suite. - [ ] Each new assertion demonstrated failing against a deliberate break, with captured output in the PR body. - [ ] No existing test or helper weakened to accommodate them. - [ ] `TODO.md` updated in the same commit. - [ ] `make check` passes.

clawbot referenced this issue from a commit

2026-08-17 08:10:40 +02:00

test: assert the #150 and #151 items the harness did not cover (closes #188)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#295