Key takeaways
- Foundry supports contract development and testing with Solidity-focused tools.
- Fuzzing and invariant tests explore behaviour beyond isolated examples.
- Results depend on the properties, scenarios and boundaries specified in the tests.
What is Foundry?
Foundry combines tools for developing, testing and operating EVM contracts. Forge handles compilation, tests and scripts; Cast provides queries and interactions; Anvil supplies a local node; and Chisel supports Solidity exploration. Projects can combine these tools according to their requirements.
Writing tests in Solidity places calls and properties close to the contract language. Their value lies in checking system rules and reproducing failures rather than assuming that a fast tool makes every test suite correct or sufficiently representative of the product's risks.
How it works
Unit tests check specific scenarios. Fuzzing generates inputs, while invariant tests explore action sequences and check properties such as balance conservation or issuance limits. Handlers and constraints determine which states and participants are actually explored by those tests.
Cheatcodes control test conditions. Forks use network data at a selected block and require suitable RPC access. Pinning block, compiler and dependencies supports reproducibility; tests against changing state may fail for reasons unrelated to the code change being assessed, obscuring the actual regression.
What Foundry offers
For escrow, tests can compare deposits, withdrawals and remaining balances across sequences involving different users. External contracts can be modelled to revert, return unexpected values or attempt reentrancy. These tests provide evidence about behaviour relevant to the product rather than only successful individual calls.
Deployment scripts prepare and simulate actions before submission. Deliveries retain parameters, artifacts and verified addresses for each network. Cast can inspect permissions or state during incidents, with a clear distinction between read-only queries and state-changing operations requiring a signature and operational authorisation.
Limitations and selection criteria
Fuzzing and invariant testing are not formal proofs covering every possible execution. Their effectiveness depends on the properties written, reachable states and exploration time. High line coverage does not establish that the risks most relevant to the product have been tested.
Foundry can coexist with Hardhat when compilers, paths and options are aligned. Selection includes integration tests, scripts and maintenance of the combined workflow. Production also requires key and permission controls and destination-network checks; local simulation does not remove those responsibilities from the delivery process.
Also known as
- Forge
- Cast
- Anvil
- Foundry-rs





