Smart Contract Auditing and Testing: From Unit Tests to Fuzzing, Invariants, Static Analysis, and Pre-Mainnet Reviews

Tooling stack for smart contract testing

A strong smart contract testing stack should cover fast local tests, integration tests, mainnet fork tests, fuzzing, invariants, static analysis, coverage, and deployment safety. No single tool catches everything. The goal is layered defense.

Foundry is one of the most useful tools for Solidity-native testing. It lets developers write tests in Solidity, use cheatcodes, run tests quickly, fork live networks, fuzz inputs, and write invariant tests without leaving the Solidity environment.

Hardhat remains powerful for JavaScript and TypeScript-heavy teams. It is especially useful when contracts need to be tested alongside front-end flows, scripts, deployment tasks, app integrations, and plugin-based workflows.

Slither adds static analysis. It reviews the code without executing it and flags common vulnerability patterns, suspicious code smells, inheritance mistakes, reentrancy risks, shadowing, unchecked logic, missing events, and dangerous patterns.

The Graph, custom indexers, and RPC providers become useful when a protocol needs to validate emitted events, accounting flows, historical data, fork scenarios, and integration behavior against real network conditions.

Test taxonomy: what each test type should prove

Not every test has the same purpose. A strong suite uses different test types for different failure classes. Unit tests prove that specific functions work. Integration tests prove that contracts interact correctly. Fork tests prove that the system behaves against real deployed infrastructure. Fuzz tests explore many inputs. Invariant tests prove that core rules remain true across many sequences.

Unit tests should be fast and focused. They should test one function or one behavior at a time. Integration tests should simulate real flows across multiple contracts. Scenario tests should follow end-to-end user stories such as deposit, borrow, repay, liquidate, claim, pause, upgrade, and withdraw.

Negative tests are just as important as positive tests. If a function should revert when a user has no permission, zero amount, stale oracle, expired deadline, invalid recipient, or insufficient balance, the test suite should explicitly prove it.

Foundry example for unit tests and fuzzing

Foundry lets developers write tests directly in Solidity. This is useful because developers can test contract logic using the same language, import helper libraries, and use cheatcodes to control addresses, balances, timestamps, blocks, and external calls.

A simple Foundry test usually lives inside the test/ folder and imports forge-std/Test.sol. The setUp() function prepares the test state before each test.

// SPDX-License-Identifier: MIT
```

pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/Vault.sol";

contract VaultTest is Test {
Vault v;
address alice = address(0xA11CE);

```
function setUp() public {
    v = new Vault();
    vm.deal(alice, 10 ether);
}

function testDeposit() public {
    vm.prank(alice);
    v.deposit{value: 1 ether}();

    assertEq(v.balanceOf(alice), 1 ether);
    assertEq(address(v).balance, 1 ether);
}

function testFuzz_Deposit(uint128 amount) public {
    amount = uint128(bound(amount, 1e9, 10 ether));

    vm.deal(alice, amount);
    vm.prank(alice);
    v.deposit{value: amount}();

    assertEq(v.balanceOf(alice), amount);
}
```

}

The first test checks one specific deposit. The fuzz test checks many possible deposit amounts within a valid range. This is already stronger than a single fixed input because it forces the contract to behave correctly under many different values.

Foundry cheatcodes to know

Cheatcodes are one reason Foundry is useful for security testing. vm.deal sets ETH balances. vm.prank impersonates a caller. vm.warp changes time. vm.roll changes block number. vm.expectRevert verifies failure behavior. vm.mockCall mocks external contract responses.

forge test -vvv
```

forge test --fork-url $RPC
forge snapshot
forge coverage

A good Foundry suite should combine white-box tests that inspect internal logic through hooks and black-box tests that simulate how real users interact with the system. Critical events, storage changes, access controls, fee behavior, and emergency paths should all be tested.

Hardhat example for integration tests

Hardhat is especially useful when the development environment is TypeScript-heavy. It works well for contract deployment scripts, front-end simulation, fixtures, plugin integrations, coverage reports, and tests that resemble production app flows.

import { expect } from "chai";
```

import { ethers } from "hardhat";

describe("Vault", () => {
it("deposits ETH", async () => {
const [user] = await ethers.getSigners();

```
const Vault = await ethers.getContractFactory("Vault");
const v = await Vault.deploy();
await v.waitForDeployment();

await user.sendTransaction({
  to: await v.getAddress(),
  value: ethers.parseEther("1")
});

expect(await v.balanceOf(user.address)).to.equal(
  ethers.parseEther("1")
);
```

});

it("reverts on withdraw more than balance", async () => {
const [user] = await ethers.getSigners();

```
const Vault = await ethers.getContractFactory("Vault");
const v = await Vault.deploy();
await v.waitForDeployment();

await expect(
  v.connect(user).withdraw(ethers.parseEther("1"))
).to.be.reverted;
```

});
});

Hardhat is also useful for network forking. Fork tests let you interact with real deployed contracts in a local environment. This is valuable for protocols that depend on real DEX routers, ERC-20 tokens, Chainlink feeds, lending markets, bridges, and upgradeable contracts.

networks: {
```

hardhat: {
forking: {
url: process.env.RPC_URL
}
}
}

A reliable RPC endpoint matters for fork testing because slow or unstable RPC calls can break CI, slow test execution, or produce inconsistent developer workflows. Teams that need managed RPC infrastructure for fork tests and contract simulations can compare providers such as Chainstack, QuickNode, and GetBlock depending on chain support, rate limits, archive access, latency, and budget.

Fuzz testing smart contracts

Unit tests check specific inputs. Fuzz tests throw many randomized inputs at a function to see whether the contract breaks under edge cases. This is useful for amounts, timestamps, ratios, fees, caps, shares, withdrawal values, debt values, oracle prices, and user balances.

A fuzz test should start from a valid state. Random inputs should be constrained with realistic bounds. Without bounds, the fuzzer may waste time testing impossible states instead of dangerous realistic ones.

function testFuzz_WithdrawNeverExceedsBalance(
uint96 depositAmount,
uint96 withdrawAmount
```

) public {
depositAmount = uint96(bound(depositAmount, 1e12, 10 ether));
withdrawAmount = uint96(bound(withdrawAmount, 0, depositAmount));

```
v.deposit{value: depositAmount}();

uint256 balanceBefore = v.balanceOf(address(this));

v.withdraw(withdrawAmount);

assertEq(
    v.balanceOf(address(this)),
    balanceBefore - withdrawAmount
);
```

}

Fuzzing is strong for discovering edge cases that developers did not manually write. It can reveal rounding issues, overflow assumptions, underflow assumptions, boundary mistakes, fee calculation bugs, and accounting drift.

Invariant testing

Invariant testing asks a different question: what must always be true, no matter what sequence of actions happens? Instead of testing one function call, invariant testing explores many calls in many orders and verifies that a core rule never breaks.

For a vault, a basic invariant might be that total user liabilities should equal the ETH held by the contract. For a lending protocol, collateral accounting must remain solvent under supported assumptions. For an AMM, reserves and shares should follow the pool rules. For an upgradeable contract, storage layout must not corrupt balances after an upgrade.

contract Invariants is Test {
Vault v;

address alice = address(0xA1);
address bob = address(0xB2);

function setUp() public {
    v = new Vault();

    targetContract(address(v));

    vm.deal(alice, 100 ether);
    vm.deal(bob, 100 ether);
}

function invariant_AccountingConserves() public {
    uint256 totalLiabilities =
        v.balanceOf(alice) + v.balanceOf(bob);

    assertEq(totalLiabilities, address(v).balance);
}
```

}

Useful invariants include: total shares never exceed supply rules, no user can withdraw more than deposited, fee recipient share never exceeds configured limits, protocol debt never becomes negative, paused functions remain blocked, and storage layout remains safe after upgrades.

Static analysis and coverage

Static analysis tools review source code without executing the full test suite. They do not prove that a protocol is safe, but they are excellent for catching common mistakes early.

Slither can flag reentrancy patterns, dangerous tx.origin usage, shadowed variables, uninitialized storage pointers, weak access control patterns, unchecked transfer assumptions, missing events, unused return values, and suspicious inheritance structures.

slither . --checklist --exclude-informational
```

forge test --fork-url $RPC --gas-report
forge coverage --report lcov

# Hardhat alternative

npx hardhat coverage

Coverage should be used carefully. High line coverage does not mean a contract is safe. A test suite can touch many lines without checking the right properties. Coverage is useful for finding missing branches, but it must be paired with assertions, negative tests, fuzzing, invariants, and manual review.

Critical paths deserve special attention: access-control modifiers, upgrade hooks, emergency pause logic, fee changes, reward distribution, withdrawal paths, liquidation logic, oracle reads, bridge calls, and accounting updates.

Storage layout and upgrade safety

Upgradeable contracts add a special class of risk. A proxy upgrade can accidentally overwrite old storage slots, corrupt balances, change ownership, break accounting, or bypass initialization rules.

Teams using UUPS, Transparent Proxy, Beacon Proxy, Diamond, or other upgrade patterns should lock storage layout with tests. A new implementation should be tested against old storage assumptions before it is approved for deployment.

Versioned initializers, reserved storage gaps, explicit upgrade tests, storage layout snapshots, and multisig-controlled upgrade paths are important. A clean unit test suite is not enough if the upgrade path can corrupt production state.

Oracles and external calls

Many protocol bugs appear around external dependencies. A contract may work under normal conditions but fail when an oracle is stale, a token charges transfer fees, a router reverts, a bridge is paused, a Chainlink round is incomplete, or an ERC-20 token returns false instead of reverting.

Tests should simulate failure paths. Mock oracle prices that are stale, extreme, zero, delayed, or outside acceptable deviation bounds. Mock external calls that revert, consume unexpected gas, or return malformed values. Test how the system behaves when a sequencer is down or a bridge message is delayed.

For external calls, prefer defensive patterns. Validate return values. Use pull-over-push withdrawals where appropriate. Apply checks-effects-interactions. Add reentrancy guards when needed. Avoid unnecessary external calls during sensitive state transitions.

Smart contract audit checklist

An audit checklist helps teams reach a clean pre-audit state. It forces developers to document assets at risk, attacker models, roles, trust assumptions, upgrade controls, economic limits, oracle assumptions, and emergency procedures.

Pre-mainnet gate

Before mainnet deployment, the team should pass a strict gate. This is not just about whether tests pass locally. It is about whether the protocol can survive real operating conditions.

For teams deploying valuable contracts, hardware wallets can reduce private key exposure for deployer and admin operations. A hardware wallet such as Ledger can help secure signing workflows, but it does not replace multisig controls, transaction review, timelocks, and operational discipline.

Rehearse a chaos day

A chaos day is a controlled rehearsal where the team simulates failure. This is useful before launch because many incident response plans look good in a document but fail under pressure.

Simulate an oracle outage. Simulate sequencer downtime. Simulate an emergency pause. Simulate a broken reward distributor. Simulate an upgrade rollback. Simulate a compromised guardian. Simulate high gas during a needed transaction. Watch whether dashboards, alerts, runbooks, team communication, and multisig execution actually work.

The goal is not to create drama. The goal is to find weak processes before attackers, markets, or users find them.

How to prepare for an external audit

External auditors work better when the codebase is organized, documented, tested, and threat-modeled. A messy repository wastes review time. A clean repository lets auditors spend more time finding real issues instead of guessing how the system should work.

Before sending code to auditors, freeze the scope. Include architecture diagrams, contract descriptions, privileged role mappings, deployment assumptions, known limitations, invariant list, test instructions, coverage reports, Slither output, and any accepted design risks.

High-TVL protocols should consider multiple independent reviews and a public bug bounty after audit fixes are merged. Audits reduce risk, but they do not eliminate it. Continuous monitoring, restricted permissions, conservative rollout limits, and emergency controls still matter.

Recommended developer workflow

A practical smart contract security workflow should be repeatable. Developers should not wait until the end of the build to think about security. Testing and review should be part of every pull request.

Quick check

Use these questions to test whether the core concepts are clear.

Final recommendation

Smart contract security should be treated as an engineering discipline, not a launch checklist. A formal audit helps, but it cannot replace a disciplined test suite, clear invariants, careful fork tests, static analysis, secure deployment controls, and emergency runbooks.

Foundry and Hardhat solve different parts of the workflow. Foundry gives speed, Solidity-native tests, fuzzing, and invariants. Hardhat gives excellent TypeScript integration and deployment ergonomics. Slither adds early static analysis. Fork tests connect the system to real chain behavior. Invariants protect the assumptions that must never break.

The safest teams test like attackers, document like auditors, deploy like operators, and rehearse like something will eventually fail. That mindset is what separates mainnet-ready systems from contracts that only worked in a demo.

FAQs

References

Official documentation and reputable sources for deeper reading:

• Foundry Book
• Hardhat Docs
• Slither Static Analyzer
• OpenZeppelin Docs
• Solidity Documentation
• Smart Contract Weakness Classification Registry
• Smart Contract Best Practices
• TokenToolHub: Token Safety Checker
• TokenToolHub: Approval Allowance Checker
• TokenToolHub: Advanced Blockchain Guides

This guide is for educational smart contract security research only and is not financial, investment, legal, or professional audit advice. Smart contract testing, static analysis, and external audits reduce risk but do not eliminate it. Always verify current tool documentation, test your own contracts under realistic assumptions, and seek independent professional review before deploying contracts that control user funds.