Why Each Test Layer Proves Different Things for Code That Moves Funds

Passing unit tests and valid calldata do not guarantee that an onchain executor will send funds only along the intended path. The article argues that a testing ladder with distinct stages (pure simulation, forked-chain execution, trivial-amount production canaries, and staged production use) is needed, since no single stage replaces the others. It warns that a scattered dryRun flag is risky because any transaction path that ignores it can broadcast funds and create false confidence. The recommended design separates a deterministic planner, which outputs an explicit transaction plan without signing capability, from a transport layer that handles simulation or live execution. Fork tests are presented as catching ABI, approval, decimal, and multi-call errors that pure simulation misses, though they still do not capture real RPC latency, mempool ordering, or reorgs.