Foundry Testing Patterns: Fuzz, Invariant, and Fork

Frequently Asked Questions

01.What is the difference between fuzz testing and invariant testing in Foundry?

A Foundry fuzz test takes one or more parameters and Forge calls the function many times with random inputs, asserting a property on each isolated call. An invariant test is stateful: Forge generates random sequences of calls across the contract and checks that a property holds after every sequence, not only a single call. Fuzz testing finds bad inputs to one function, while invariant testing finds bad sequences of state transitions, which is where most protocol bugs live.

02.Why use handler contracts in Foundry invariant tests?

Unconstrained invariant testing lets Forge call functions with arguments that always revert, wasting runs on paths that never execute real state changes. A handler contract wraps the system under test and exposes bounded functions that constrain inputs to realistic ranges and track ghost variables. This focuses the fuzzer on reachable states and makes invariant violations meaningful rather than noise from reverting calls.

03.When should you use fork testing instead of a local deployment?

Fork testing runs your contracts against a real copy of mainnet state at a chosen block, so integrations with live protocols, oracles, and token contracts behave exactly as they do in production. Use it when correctness depends on external state you cannot faithfully mock, such as a live AMM pool, a lending market, or a price oracle. Local deployment is faster for unit logic, but only a fork validates real integration behaviour.