#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.
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.