unit-test

Unit Test Skill

Generate Foundry unit tests for a specific contract, adhering to our established directory structure, naming conventions, and best practices. The tests should include both concrete scenarios and property-based fuzz tests, with clear organization and comprehensive coverage. Follow the guidelines below to ensure consistency and maintainability across our test suite.

1. Directory Layout

contracts/tests/unit/<category>/<ContractName>/
├── shared/
│   └── Shared.sol          # Abstract base with setUp, mocks, helpers
├── concrete/
│   ├── FunctionA.t.sol     # One file per public/external function
│   ├── FunctionB.t.sol
│   └── ViewFunctions.t.sol # Exception: all view/pure functions grouped in one file
└── fuzz/
    ├── FunctionA.fuzz.t.sol # Property-based tests per function
    └── FunctionB.fuzz.t.sol

<category> matches the subdirectories already in contracts/tests/unit/ (vault, token, strategies, oracle, etc.).

One file per function rule

Each public/external state-changing function gets its own dedicated test file, named after the function in PascalCase (e.g. rebaseOptIn() → RebaseOptIn.t.sol, delegateYield() → DelegateYield.t.sol).

Exceptions (may be grouped into a single file):

• View/pure functions → group in ViewFunctions.t.sol
• Setter functions (governor/admin config) → group in Admin.t.sol or Config.t.sol

Do NOT group multiple distinct functions in one file just because they are thematically related. For example, rebaseOptIn() and rebaseOptOut() are two separate functions and must have two separate files, even though they are conceptually related.

2. Inheritance Chain

forge-std/Test
  └─ Base  (contracts/tests/Base.sol)  — actors, constants, external token refs
       └─ Unit_Shared_Test  (shared/Shared.sol)  — abstract; setUp, deploy, helpers
            ├─ Unit_Concrete_<Contract>_<Feature>_Test  (concrete/*.t.sol)
            └─ Unit_Fuzz_<Contract>_<Feature>_Test      (fuzz/*.fuzz.t.sol)