A Practical Guide to Test-Driven Development in DeFi Smart Contracts

When the lights in my office dimmed after a long trading day, I found myself staring at a small piece of code that looked almost the same as the last one we deployed. I was thinking of the usual sprint‑time check‑list—functions deployed, variables compiled, gas estimated. Nothing else. It felt safe, comfortable, familiar. Yet the last three months of market noise had reminded me that DeFi is a kind of garden where a single misstep can bring down an entire ecosystem. In that quiet moment by the desk, I realised that the only true safety net for a smart contract is the code written before it runs. That’s why test‑driven development (TDD) has become my compass.

Why We Need TDD in DeFi

When a smart contract is written in Solidity or Vyper, it is immutable once on the blockchain. Imagine planting a seed knowing that if it has a disease it will spread forever. In finance we talk about market timing; in smart contracts we talk about contract timing—that is, the moments when external parties call your contract. The real world is noisy, so your code should speak louder.

Fear is the underlying emotion most of the time. Users will trust your contract with money. If a re‑entrancy bug slips through, the loss is not abstract; it is coins that suddenly vanish. TDD is less about avoiding fear and more about acknowledging that fear is always around, so we build a plan to mitigate it.

What does TDD bring?

• Clarity of intent – you write what the contract should do before you write how it does it.
• Confidence – you can redeploy often because you know the tests guard against regressions.
• Documentation – tests are living examples of the expected behaviour.
• Early detection – bugs that would cost millions surface before they hit production.

Think of it this way: you’re planting a garden. TDD is like planting a row of seedlings, each one inspected before you let it grow. If one shows signs of disease, you pull it out before it pollutes the rest of the garden.

Foundations: The Toolbelt

Before you start writing code, gather the essential tools. I’ve settled on a minimal yet powerful stack because that keeps us focused on the reasoning behind the tests, not on wrestling the tooling.

• Foundry – a fast Rust‑based framework for Solidity that compiles, runs, and benchmarks tests. It’s lightweight and integrates well with local dev chains.

• Hardhat – a JavaScript‑centric environment that supports custom scripts, network deployments, and detailed debugging. You can keep Foundry for tests and Hardhat for deployment scripts.

• Anvil – built into Foundry, it spins up a local fork of the mainnet. That lets you write tests that interact with real‑world data such as Chainlink oracles or Uniswap pools, but in a sandboxed environment.

• Chainlink’s MockAggregator contracts – to simulate price oracles in a deterministic way.

• GitHub Actions – for continuous integration so that every push triggers a full test sweep.

• Solidity test coverage tool – to spot untested paths, especially if you have intricate fee calculations.

If you’re new, start with Foundry because it is simpler to learn from a single language. Once comfortable, add Hardhat for complex deployment flows.

Writing Your First Test: A Step‑by‑Step Walk‑through

Let’s walk through a tiny DeFi contract that implements a flash loan “receiver” interface. The contract is straightforward: it pulls a flash loan from a lending pool and immediately returns the borrowed amount plus a fee. In a real world, we might also do arbitrage inside the callback, but we’ll keep it simple to demonstrate the workflow.

pragma solidity ^0.8.20;

interface IFlashLoanReceiver {
    function executeOperation(
        address asset,
        uint256 amount,
        uint256 fee,
        bytes calldata params
    ) external returns (bool);
}

contract SimpleFlashLoan is IFlashLoanReceiver {
    address public owner;
    IFlashLoanPool public pool; // assumed to exist

    constructor(address _pool) {
        owner = msg.sender;
        pool = IFlashLoanPool(_pool);
    }

    function startFlashLoan(address asset, uint256 amount) external {
        require(msg.sender == owner, "only owner");
        pool.flashLoan(asset, amount, address(this), "0x");
    }

    function executeOperation(
        address asset,
        uint256 amount,
        uint256 fee,
        bytes calldata
    ) external override returns (bool) {
        // ... arbitrage logic here
        IERC20(asset).transfer(address(pool), amount + fee);
        return true;
    }
}

Now we write tests, following the TDD principle: write failing test → make it pass → refactor.

1. Create a test file: tests/simple_flash_loan.t.sol

2. Initialize the test environment:

import { Test, console } from "forge-std/Test.sol";
import { SimpleFlashLoan } from "../src/SimpleFlashLoan.sol";
import { DummyPool } from "../src/DummyPool.sol";
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";

contract SimpleFlashLoanTest is Test {
    SimpleFlashLoan loan;
    DummyPool pool;
    IERC20 token;
    address alice = address(0xAlice);

3. Set up a mock token and a dummy pool in setUp():

    function setUp() public {
        token = IERC20(address(new MockERC20()));
        pool = new DummyPool(address(token));
        loan = new SimpleFlashLoan(address(pool));
        vm.label(address(token), "TOKEN");
        vm.label(address(pool), "POOL");
        vm.label(address(loan), "LOAN");
    }

4. Write the first test – flash loan fails without permission:

    function testRevertsIfNotOwner() public {
        vm.expectRevert("only owner");
        loan.startFlashLoan(address(token), 1000);
    }
}

Compile and run forge test. The test fails as expected, because the require check is triggered. This verifies that the environment reflects the intended state.

5. Make the test pass – In practice the code is already correct, but to mimic the process, deploy the contract as the owner and call the function:

    function testOwnerCanStartFlashLoan() public {
        vm.prank(alice);
        vm.expectRevert("only owner");
        loan.startFlashLoan(address(token), 1000);

        // Make Alice the owner by deploying
        loan = new SimpleFlashLoan(address(pool));
        vm.prank(address(loan));
        loan.startFlashLoan(address(token), 1000); // now should not revert
    }

6. Add test for the callback execution – ensure that after the executeOperation the pool receives the loan plus fee:

    function testExecOperationReturnsTokenToPool() public {
        // Set balances
        token.mint(alice, 10000);
        vm.prank(alice);
        loan.startFlashLoan(address(token), 5000);

        // In DummyPool, we check that the transfer happened.
        assertEq(token.balanceOf(address(pool)), 5000 + DummyPool.FEE());
    }

After every change, run forge test. If any test fails, you’ll immediately know why.

Structuring Tests for Smart Contracts

Smart contracts have a few peculiarities that standard unit tests don’t cover. Here’s a quick catalogue of patterns I use:

• Pre‑deployment – mock all dependencies. That includes tokens, oracles, and other contracts that your contract interacts with. If you rely on Chainlink, deploy a MockAggregator and feed it with static data.

• State snapshotting – use vm.snapshot() to capture a known good state and revert between tests. It keeps test isolation intact.

• Gas profiling – include vm.recordGas() to make sure that new features don’t cost more than a threshold. In DeFi the gas can represent a real monetary cost.

• Event expectation – vm.expectEmit() and then assert the presence of log events. This is powerful for auditing state changes: you can check that the FlashLoanExecuted event logs the same values the contract used internally.

• Edge cases – test boundary values such as zero amounts, maximum uint256, and rounding errors. These are where many audit failures happen.

For each of these patterns write a first test that fails, then refine the contract to satisfy the test, then run coverage to ensure that all paths are exercised. Remember, more tests don’t always equal better security; they’re more reliable when they reflect realistic usage scenarios.

Common DeFi Pitfalls to Guard Against

1. Re‑entrancy – The classic transfer problem. Make sure you use the checks‑effects‑interactions pattern, or the ReentrancyGuard modifier if the code is more complex.

2. Price manipulation – If you rely on an oracle that can be corrupted by a flash loan, add a time‑lock or use an aggregator that aggregates multiple feeds. In tests, simulate an attacker sending a large flash loan to skew the price.

3. Allowance loopholes – When interacting with ERC20 tokens, always check the allowance returned by safeApprove. A malicious token could return false or revert silently; your test should catch that.

4. Integer overflow/underflow – Not a worry with Solidity 0.8+, but be mindful of unchecked blocks. Add tests that intentionally push near the limits to confirm that overflows trigger.

5. Denial‑of‑service via gas limits – If you call external contracts, wrap them in a try/catch or limit the gas forwarded. Tests where the external call consumes all gas should validate that your function still behaves deterministically.

6. Replay attacks – Nonces for flash loans or permit calls are essential. Add tests to confirm that re‑using a nonce fails.

Creating a small catalog of these pitfalls within your test suite not only protects the contract but also educates future developers who inherit the code.

Integrating TDD into a CI/CD Pipeline

Once the tests are written and local coverage is satisfactory, make sure they run in Continuous Integration. I like to set up a simple GitHub Actions workflow that builds, tests, and runs a coverage report:

name: Test
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install Foundry
        run: |
          curl -L https://foundry.paradigm.xyz | bash
          source ~/.bashrc
          forge install
      - name: Run tests
        run: forge test --via-ir --no-compile --report gas

The --via-ir flag ensures the compiler uses the intermediate representation, catching low‑level issues earlier. You can also run forge coverage to verify that the tests hit all branches. Add a failing step if the coverage drops below a threshold—this enforces discipline.

Maintaining Tests as Contracts Evolve

Smart contracts rarely stay static. New features mean new tests, and old tests mean new maintenance overhead. Here are strategies to keep the test suite healthy:

• Keep tests small, focused, and idempotent. A test that touches many parts of the system should be split into multiple narrower tests.
• Use helper libraries – create a TestUtils.sol that contains common patterns like makeFlashLoan, assertRevert. This reduces duplication.
• Prune dead tests – if a function is removed, find the tests that referenced it and delete or repurpose them. A stale test can mask new bugs.
• Document test expectations – add comments describing the business rationale next to important assertions. When the spec changes, that comment will guide the refactoring.

At the end of each sprint, do a quick health check: run coverage, verify that failing tests are intentional, and ensure no test is silent.

The Human Side of Testing

When you’re debugging a failing test, the first instinct might be to jump into the code and fix it. But remember that a test is a conversation with future you. In my early days, an oversight in a require statement cost a client a week of research and a decent sum of money. The lesson? Treat every failing test as an apology to your client and a promise that this path will never happen again.

We’re not just coders; we are storytellers of trust. A well‑written test suite speaks for your contract’s reliability. Think of it as a friendly hand lifting the veil on what the contract does. People reading your tests will get an honest snapshot of the contract’s behaviours—a transparency that goes beyond whitepapers and audit reports.

Takeaway

1. Start small – write a single failing test for your first function and make it pass. This forms the habit.
2. Mock everything – create deterministic substitutes for external contracts and oracles. You’ll catch price manipulation risks early.
3. Protect the garden – guard against flairs: re‑entrancy, underpayment, and gas overuse with explicit tests.
4. Automate relentlessly – pull the tests into CI so that every commit gets a full sweep.
5. Iterate mindfully – keep the tests readable, organized, and anchored to business intent.

Let’s zoom out. If you view a DeFi protocol as a garden, each test is a pruning shears that keeps the vines healthy. The more you prune, the less likely a disease will spread. TDD isn’t a shield against uncertainty; it’s a mindful cultivation of certainty. Markets test patience before rewarding it, and your test suite will remind you that patience is a kind of currency we can spend in code.