unit-test

Generates Foundry unit tests for Solidity contracts following repository conventions.

152|115|Updated Aug 3, 2020
One-click install
npx skills add https://github.com/OriginProtocol/origin-dollar --skill unit-test-originprotocol
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: unit-test
Source: https://github.com/OriginProtocol/origin-dollar/tree/main/.codex/skills/unit-test
Command: npx skills add https://github.com/OriginProtocol/origin-dollar --skill unit-test-originprotocol

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing Foundry tests that match an existing codebase's conventions is slow and error-prone: directory layout, inheritance chains, naming rules, and interface-only imports all vary per repository. This Skill generates unit tests for OUSD/OETH contracts that conform exactly to this repository's established structure and style. ## Core Features & Use Cases - Convention-compliant test generation: Produces concrete and fuzz tests with the correct directory layout (unit/<category>/<Contract>/concrete|fuzz), inheritance chain (BaseUnit_Shared_Test → concrete/fuzz test contracts), and naming patterns (test_<fn>_RevertWhen_<condition>, testFuzz_<fn>_<property>). - Interface-only testing enforcement: Ensures tests import interfaces (IVault, IOToken, IWOToken, IProxy) instead of concrete contracts, deploy via vm.deployCode with artifact paths from tests/utils/Artifacts.sol, and emit events from interfaces. - Shared setup scaffolding: Generates Shared.sol with the canonical setup order (mocks, deployments, configuration, funding, labels) and proxy initialization patterns. - Use Case: You added a new rebaseOptIn function to a vault contract and need both concrete revert-path tests and fuzz coverage of its arithmetic properties, matching the repo's existing test suite style. ## Quick Start Ask the AI to generate Foundry unit tests, including concrete and fuzz coverage, for a specific contract function following this repository's test conventions.

Frequently Asked Questions about unit-test

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

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

Create one test file per public state-changing function under a concrete/ directory, inheriting from a shared setup contract. Name tests with patterns like test_<function>_RevertWhen_<condition> and use vm.expectRevert with exact revert strings.

How to write fuzz tests in Foundry with proper input bounds?

Use testFuzz_<function>_<property> naming and prefer bound() over vm.assume() to constrain inputs, for example bound(amount, 1e12, 100e18) for token amounts. Use assertEq for exact math and assertApproxEqAbs where rounding is expected.

Should Foundry tests import interfaces or concrete contracts?

Tests should import interfaces (such as IVault or IOToken) rather than concrete implementations, declare state variables with interface types, and emit events from interfaces. This keeps tests decoupled from implementation changes.

Why use vm.deployCode instead of new in Foundry tests?

vm.deployCode deploys from compiled artifacts referenced through a central Artifacts library, avoiding inline artifact path strings and keeping deployments consistent. Note that forge build must be run before forge test after modifying contract source, since deployCode loads compiled artifacts.

How do I test proxy contracts with Foundry?

Deploy the implementation with vm.deployCode, then deploy the proxy and call proxy.initialize(impl, governor, initData). Cast the proxy address to the interface type, for example IOToken(address(proxy)), and use vm.startPrank(governor) for admin configuration.