An audit is a photograph, a test suite is a habit

A smart contract audit reviews one version of the code, at one moment, by people who did not write it. That is valuable work, and it is also a photograph. It says nothing about the next commit, and the code will have many of them.

What the audit does not cover

After the report is delivered, the code keeps changing. A dependency is updated, a fee parameter is adjusted, a function is added for one customer, a deployment script is edited at the last minute. None of these changes is described by a document dated three months earlier. The audit remains true about the version it examined, and becomes less informative about the version that is actually deployed with every change made since. This is the ordinary life of any codebase, and it is why a single dated report cannot be the only evidence that a contract behaves as intended. The question a reviewer should ask is not whether an audit exists, but how much of the deployed code it still describes.

Three kinds of test that carry the audit forward

Unit tests check each function in isolation and are the baseline. Fork tests run your contracts against a copy of real chain state, so the integration with protocols that are already deployed is exercised rather than assumed. Invariant tests state properties that must hold whatever happens: the sum of balances equals the total supply, nobody can withdraw more than they deposited, a paused contract accepts no transfers. A fuzzer then generates sequences of calls that try to break each property, including sequences nobody on the team thought of. Tools such as Foundry and Hardhat support all three styles.

Tests for the parts that are not contract logic

Many production incidents come from deployment and upgrade, not from the logic the audit read. Put the deployment scripts, the constructor and initializer arguments, and the upgrade path inside the suite. Run everything in continuous integration on every change, so that a failing invariant stops a release the same way a failing unit test would in any other codebase.

How to use the auditor

Ask the auditor to hand over each finding as a reproduction, and turn it into a failing test before fixing it. A finding that becomes a test does not come back unnoticed. Ask also which invariants they assumed while reading, and write those down as tests. The result is a suite that records what the audit learned, so the next reviewer starts from it instead of from zero.

The rule is short. The audit is a milestone and the test suite is the process. Which invariant of your contract is not written down as a test today?