本文へ移動
cccskills
無料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.

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollarスター 154(GitHub 154 + cccskills 0)

実行スコア 未検証

インストール方法を見る

含まれるファイル(1)

  • SKILL.md6.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

commit

無料

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.

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollar1542026年10月26日 更新

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.

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollar1542026年10月26日 更新

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.

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollar1542026年10月26日 更新

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.

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollar1542026年10月26日 更新

unit-test

無料

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.

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollar1542026年10月26日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

OriginProtocol/origin-dollar1542026年10月26日 更新

OriginProtocol のスキルをすべて見る

このスキルの問題を報告する