Skip to content
cccskills
FreePublished on GitHub

smoke-test

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-dollar154 stars(GitHub 154 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md6.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Smoke Test

Generate Foundry smoke tests that verify deployment health by bootstrapping the actual deployed state (including pending governance) via the DeployManager/Resolver pipeline.

0. How smoke tests differ

AspectUnit TestsFork TestsSmoke Tests
StateFresh deploys with mocksFresh deploys on forkActual deployed state via Resolver
PurposeFull coverage, fuzzIntegration pathsVerify deployment health
ContractsDeployed in setUpMix fresh + forkedAll resolved from DeployManager
ActorsmakeAddr("Governor")makeAddr("Governor")ousd.governor() (live)
TokensMockERC20.mint()deal()deal()
FuzzYesNoNo

Smoke tests answer "Is this deployment safe to execute?" — not "Does this code work?"

1. Directory layout

contracts/tests/smoke/<category>/<Product>/
├── shared/
│   └── Shared.t.sol
└── concrete/
    ├── ViewFunctions.t.sol
    ├── Mint.t.sol
    ├── Redeem.t.sol
    └── Transfer.t.sol

Rules:

  • smoke tests are concrete only; no fuzz/ directory
  • one file per feature area, not per function
  • feature groupings depend on the contract being tested (e.g. for OTokens: ViewFunctions, Mint, Redeem, Transfer, Rebasing, YieldDelegation)

2. Inheritance chain

forge-std/Test
  └─ Base
       └─ BaseFork
            └─ BaseSmoke
                 └─ Smoke_<Product>_Shared_Test
                      └─ Smoke_Concrete_<Product>_<Feature>_Test

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

BaseSmoke provides:

  • resolver — deterministic address: Resolver(address(uint160(uint256(keccak256("Resolver")))))
  • _igniteDeployManager() — runs the full deployment pipeline: parse JSON, etch Resolver, replay scripts, simulate governance

Interface-only testing

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

  • Declare state variables with interface types: IVault internal ousdVault;
  • Resolve and cast to interfaces: ousd = IOToken(resolver.resolve("OUSD_PROXY"));
  • Reference events from interfaces: emit IVault.YieldDistribution(...);
  • Available interfaces: IVault, IOToken, IWOToken, IProxy, plus strategy interfaces in contracts/interfaces/strategies/

Product-specific vault types

ProductTokenVaultChain
OUSDOUSDOUSDVaultMainnet
OETHOETHOETHVaultMainnet
OETHBaseOETHBaseOETHBaseVaultBase

3. Shared setup contract

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

function setUp() public virtual override {
    super.setUp();
    _createAndSelectFork<Chain>();
    _igniteDeployManager();
    _fetchContracts();
    _resolveActors();
    _labelContracts();
}

Critical rules:

  • no fresh deploys — everything comes from the Resolver or fork state
  • resolve contracts by name and cast to interfaces: ousd = IOToken(resolver.resolve("OUSD_PROXY"))
  • resolve actors from live contracts: governor = ousd.governor()
  • sanity-check the Resolver: require(address(resolver).code.length > 0, "Resolver not initialized")

4. Concrete test naming

File and contract naming:

concrete/Mint.t.sol
Smoke_Concrete_<Product>_Mint_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 smoke tests

Smoke-test these:

  • core operations (mint, redeem, transfer) against deployed contracts
  • supply invariants (rebasingSupply + nonRebasingSupply ≈ totalSupply)
  • rebase correctness and yield distribution
  • yield delegation with real state
  • view function sanity (totalSupply > 0, governor is non-zero)
  • withdrawal queue end-to-end (request → ensure liquidity → claim)

Do not smoke-test:

  • access control (unit tests)
  • input validation (unit tests)
  • edge cases and fuzz properties (unit tests)
  • strategy internals (fork tests)

6. Key patterns

deal() for real tokens

Use deal(), not mock minting. Tokens on fork are real.

Additive deal for yield

Add to the existing balance; do not overwrite:

deal(address(usdc), address(vault), usdc.balanceOf(address(vault)) + yieldAmount);

Vault liquidity management

On mainnet fork, most tokens sit in strategies. Ensure vault liquidity before claiming withdrawals:

function _ensureVaultLiquidity(uint256 extra) internal {
    (uint256 queued, uint256 claimable,,) = vault.withdrawalQueueMetadata();
    uint256 shortfall = queued > claimable ? queued - claimable : 0;
    uint256 needed = shortfall + extra;
    if (needed > token.balanceOf(address(vault))) {
        deal(address(token), address(vault), needed);
    }
    vault.addWithdrawalQueueLiquidity();
}

Tolerant assertions

Live state has rounding. Use approximate comparisons:

assertApproxEqRel(calculatedSupply, ousd.totalSupply(), 1e14); // 0.01%
assertApproxEqAbs(balanceAfter - balanceBefore, expected, 1e18);

Rebase during mint

The vault may trigger rebase during mint. Use assertGe for total supply changes:

assertGe(totalSupplyAfter - totalSupplyBefore, mintedAmount - 1e18);

Output expectations

When implementing smoke tests:

  • keep tests focused on deployment health verification
  • use tolerant assertions throughout — live state has accumulated rounding
  • use interface-only imports; no concrete contract imports
  • cast resolved addresses to interfaces, not concrete types
  • mirror the existing OUSD smoke test structure before introducing new patterns
  • prefer a few strong invariant checks over broad but shallow coverage

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

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-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

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