clawbot
7e5d7cdcde
All checks were successful
check / check (push) Successful in 32s
The screen that decides what gets signed had no automated coverage of its own behaviour: no unit tests, and the e2e suite never reached it. The arithmetic underneath is well covered in src/shared/txValidation.js; the gap was the wiring — which number reaches the gate, when the gate re-runs, what the fee block renders, and whether Send is enabled. The confirmation screen quotes the fee ESTIMATE (gasLimit * gasPrice) and gates on the fee RESERVE (gasLimit * maxFeePerGas). Reading the quoted number instead was issue #154, and until now that was correct by reading only — a mutant swapping the two passed the whole suite. It no longer does: two of the new tests fail on it, one per transaction type. The harness gains a funded-balance fixture to make any of this reachable. tests/e2e/network.js now serves a configurable ETH balance, an ERC-20 holding, a latest block with a baseFeePerGas (without which ethers has no maxFeePerGas and the reserve and the estimate collapse into one number), and decimals() for the stub token. It can also refuse a gas estimate, and hold one open so the pending state can be observed rather than raced. Nine tests, over both the native ETH and the ERC-20 path: Send disabled while the estimate is pending, enabled once it lands, the fee block quoting both numbers, the distinct message for an estimate that failed, refusal for a send past the balance, refusal for a send the reserve does not cover, and the view height constant across every one of those transitions. Driving a failure path means provoking the console.error the code is supposed to emit, which the harness fails a run on. ErrorCollector gains expect(): it consumes exactly one matching record, and a declaration nothing matched fails its test just as an undeclared error does, so it cannot be used to silence anything. Both halves of that were verified by running the suite against a deliberately wrong pattern.
42 KiB
42 KiB