#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.
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.
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.
Built in #466: three Chrome end-to-end tests cover the four items. Adding a token by its contract address is checked on the address screen's balance list. TransactionDetail opened from the token screen is checked on the persisted navigation stack on arrival and after Back. The token contract row's explorer link is read off the link, not followed. The network stub now answers symbol() and name() for the stub token, which adding it reads.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/AutistMask/pulls/466: three Chrome end-to-end tests cover the four items. Adding a token by its contract address is checked on the address screen's balance list. TransactionDetail opened from the token screen is checked on the persisted navigation stack on arrival and after Back. The token contract row's explorer link is read off the link, not followed. The network stub now answers `symbol()` and `name()` for the stub token, which adding it reads.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
#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:
tests/touchesbtn-add-token-confirm, so the confirm path — the actual point of the screen — has no browser coverage at all.Still uncovered, from #151:
Implementation requirements
Definition of done
TODO.mdupdated in the same commit.make checkpasses.Built in #466: three Chrome end-to-end tests cover the four items. Adding a token by its contract address is checked on the address screen's balance list. TransactionDetail opened from the token screen is checked on the persisted navigation stack on arrival and after Back. The token contract row's explorer link is read off the link, not followed. The network stub now answers
symbol()andname()for the stub token, which adding it reads.Model: opus-5-5