test-foundry

Generates comprehensive Foundry/Forge test suites for Solidity contracts with fuzz, invariant, and fork testing.

Updated Apr 3, 2026
One-click install
npx skills add https://github.com/Ayoub-ouederni/SENTINEL --skill test-foundry-ayoub-ouederni
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-foundry
Source: https://github.com/Ayoub-ouederni/SENTINEL/tree/main/.claude/skills/test-foundry
Command: npx skills add https://github.com/Ayoub-ouederni/SENTINEL --skill test-foundry-ayoub-ouederni

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing thorough Solidity tests manually is slow and error-prone, and incomplete coverage of revert paths, edge cases, and invariants leaves smart contracts exposed to exploits. This Skill produces a structured, high-coverage Forge test suite for any contract or function. ## Core Features & Use Cases - Structured Test Generation: Creates unit tests ordered by reverts, happy paths, and edge cases, matching the contract's source layout for easy cross-referencing. - Fuzz, Invariant & Fork Testing: Generates testFuzz_ variants with bound() constraints, invariant tests with Handler contracts and ghost variables, and fork tests pinned to specific blocks. - Coverage Review: Prints a coverage summary verifying modifiers, require statements, events, and end-to-end flows. - Use Case: Point it at Vault.sol#42 to test only the function at that line, or pass a full contract name to get deployment tests, per-function groups, invariants, and integration scenarios. ## Quick Start Ask the AI to generate a comprehensive Foundry test suite for your contract, for example by saying: test the deposit function in Vault.sol with fuzz and invariant coverage.

Frequently Asked Questions about test-foundry

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate Foundry tests for a Solidity contract?

Provide the contract filename, a function name, or a file with line number as the argument. The Skill reads the contract and its dependencies, builds a test plan covering reverts, happy paths, and edge cases, then writes the Forge test files.

How to write invariant tests with Foundry handlers?

Create a Handler contract that wraps the target, constrains inputs with bound(), manages multiple actors, and tracks ghost variables. The invariant test contract then targets the handler and asserts properties like solvency and accounting consistency.

Should I use bound() or vm.assume() in Forge fuzz tests?

Prefer bound() to constrain inputs into valid ranges because vm.assume() discards inputs and wastes fuzzer runs. Use vm.assume() only to exclude specific impossible values such as address(0) or cheatcode addresses.

Can Foundry tests run against mainnet fork state?

Yes, fork tests use vm.createFork with an RPC URL and a pinned block number for reproducibility. You can use deal() to set token balances and impersonate whale accounts to interact with real deployed contracts.

What naming conventions should Forge tests follow?

Use test_FunctionName_Description for unit tests, testFuzz_ prefix for fuzz tests, invariant_ prefix for invariant properties, and test_Fork_ for fork tests. Order tests as reverts first, then happy path, then edge cases.