Skip to content
cccskills
FreePublished on GitHub

fork-test

Generate Foundry fork tests for contracts that need real on-chain integration coverage. Use when the user asks for fork tests, mainnet or chain fork coverage, or integration tests against live protocol state.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154 stars(GitHub 154 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md4.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Fork Test

Generate Foundry fork tests for contracts whose behavior depends on real on-chain state, live liquidity, routers, gauges, or oracle reads.

1. Directory layout

contracts/tests/fork/<category>/<ContractName>/
├── shared/
│   └── Shared.t.sol
└── concrete/
    ├── Deposit.t.sol
    ├── Withdraw.t.sol
    └── Rebalance.t.sol

Rules:

  • fork tests are concrete only; do not add a fuzz/ directory
  • create files only for functions with meaningful on-chain integration behavior
  • keep simple setters, access control checks, and pure validation in unit tests

2. Inheritance chain

forge-std/Test
  └─ Base
       └─ BaseFork
            └─ Fork_<Contract>_Shared_Test
                 └─ Fork_Concrete_<Contract>_<Feature>_Test

Base owns shared actors, constants, IERC20 external token refs, and fork IDs. All typed contract/proxy/mock state variables are declared in each Shared.t.sol using interface types. BaseFork owns chain fork helpers.

Interface-only testing

Same rules as unit tests — use interfaces, not concrete contracts:

  • Import interfaces: IVault, IOToken, IProxy, strategy interfaces from contracts/interfaces/strategies/
  • Deploy fresh contracts with vm.deployCode instead of new (except mocks), and always reference artifact paths through tests/utils/Artifacts.sol (e.g. vm.deployCode(Vaults.OETH, abi.encode(address(weth)))); add the entry to the relevant sub-library if it does not exist yet
  • Cast forked addresses to interfaces: oethVault = IVault(Mainnet.OETH_VAULT)
  • Reference events from interfaces: emit IVault.EventName(...)

Product-specific vault types

ProductTokenVaultChainArtifacts reference
OUSDOUSDOUSDVaultMainnetVaults.OUSD
OETHOETHOETHVaultMainnetVaults.OETH
OETHBaseOETHBaseOETHBaseVaultBaseVaults.OETH_BASE

Add the entry to tests/utils/Artifacts.sol if it does not exist yet.

3. Shared setup contract

shared/Shared.t.sol should keep setup in this order:

function setUp() public virtual override {
    super.setUp();
    _createAndSelectFork<Chain>();
    _deployFreshContracts();
    _configureContracts();
    label();
}

Decision rule:

  • deploy fresh contracts that the strategy or vault under test owns or manages
  • use forked addresses for external infrastructure such as routers, tokens, factories, and oracles

Pull canonical addresses from tests/utils/Addresses.sol.

4. Concrete test naming

File and contract naming:

concrete/Deposit.t.sol
Fork_Concrete_<ContractName>_Deposit_Test

Function naming patterns:

  • test_<function>()
  • test_<function>_<behavior>()
  • test_<function>_RevertWhen_<condition>()
  • test_<function>_emits<EventName>()

Casing rules:

  • function, behavior, and condition stay camelCase
  • RevertWhen is the only PascalCase token in the test name

5. What belongs in fork tests

Fork-test these categories:

  • AMO pool interactions
  • real router swaps
  • oracle reads
  • gauge reward flows
  • cross-chain and bridge flows
  • vault rebases with real balances
  • zapper flows
  • multi-step end-to-end operations

Do not fork-test:

  • simple setters
  • straightforward view functions
  • access control checks
  • constructor validation
  • pure math and helper logic
  • input-validation-only reverts

Litmus test:

If a mock can faithfully reproduce the behavior, keep it in unit tests.

6. Chain mapping

Use the repository's fork helpers and address libraries consistently:

  • Mainnet -> _createAndSelectForkMainnet()
  • Base -> _createAndSelectForkBase()
  • Arbitrum if relevant -> _createAndSelectForkArbitrum()

Output expectations

When implementing fork tests:

  • keep them narrowly focused on real integration value
  • prefer a few strong end-to-end tests over broad but redundant coverage
  • label both fresh and forked contracts for readable traces
  • use interface-only imports; no concrete contract imports except mocks
  • deploy fresh contracts with vm.deployCode, not new (mocks are fine with new), and reference all artifact paths through tests/utils/Artifacts.sol — no inline "contracts/...sol:Name" strings
  • mirror existing fork test structure in the nearest comparable test suite before introducing a new pattern

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

commit

Free

Handle git commits with auto-staging, targeted pre-commit formatting, and Conventional Commit messages. Use when the user says commit it, commit this, commit changes, save my changes, or similar git commit requests.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154Updated Oct 26, 2026

Reorganize Foundry test files (*.t.sol) for readability and consistency without changing semantics. Use when the user asks to organize, reorder, clean up, tidy, or reformat a test file's structure.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154Updated Oct 26, 2026

Generate Foundry smoke tests that validate deployment health using DeployManager/Resolver against real on-chain state with pending governance applied. Use when the user asks for smoke tests, deployment verification tests, or post-deploy health checks.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154Updated Oct 26, 2026

Develop, modify, review, and maintain standalone Talos actions in contracts/tasks/actions, including chain guardrails, contract bindings, transaction safety, schedules, action catalogues, and Talos documentation. Use when adding an action, changing an action’s behavior or parameters, updating a Talos schedule, or maintaining action runtime support.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154Updated Oct 26, 2026

Generate Foundry unit tests for a contract using this repository's conventions, structure, and naming. Use when the user asks for unit tests, Foundry tests, concrete tests, or fuzz tests.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154Updated Oct 26, 2026

Verifies a POST-EXECUTION mainnet (or other network) smart-contract deployment PR for this repo: confirms every deployed contract is listed in the PR description, that the on-chain verified source (and its dependencies) matches the codebase via `sol2uml diff`, that constructor args and the initialize tx match the Foundry script, and that the on-chain governance proposal matches the script's actions. Use when asked to review, verify, audit, or sign off on an executed deployment PR. Invoke explicitly with /verify-deployment-pr <PR#>.

The English summary is being prepared. Showing the original description.

OriginProtocol/origin-dollar154Updated Oct 26, 2026

See all skills by OriginProtocol

Report a problem with this skill