testing

Applies testing conventions for OpenZeppelin contracts across Hardhat, Foundry, Halmos, and Certora.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/urufu-labs/urufu-launchpad --skill testing-urufu-labs
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: testing
Source: https://github.com/urufu-labs/urufu-launchpad/tree/main/contracts/lib/openzeppelin-contracts/.claude/skills/testing
Command: npx skills add https://github.com/urufu-labs/urufu-launchpad --skill testing-urufu-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing tests for OpenZeppelin contracts requires choosing between Hardhat unit tests, Foundry fuzzing, Halmos symbolic execution, and Certora formal verification, and misusing any of them wastes effort or leaves coverage gaps. This Skill encodes the repository's exact conventions so tests, mocks, and verification specs are written correctly the first time. ## Core Features & Use Cases - Approach selection: Decision table mapping contract complexity to the right testing approach, from Hardhat edge-case unit tests up to Certora rule-based verification. - hardhat-exposed wrappers: Guidance on using auto-generated $-prefixed contracts to call internal functions, plus rules for when manual mocks in contracts/mocks/ are warranted. - Framework patterns: Concrete conventions for loadFixture caching, shouldBehaveLike shared behaviors, multi-target loops, Foundry fuzz functions, Halmos testSymbolic naming, and Certora .conf/.spec pairs. - Use Case: When fixing a bug in an ERC-20 extension, use this Skill to write a minimal regression test with the correct Chai assertion style, decide whether a Halmos symbolic test covers the invariant, and add the required changeset. ## Quick Start Write a Hardhat test for the ERC20 contract following this repository's testing conventions, including a fixture and custom-error assertions.

Frequently Asked Questions about testing

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

FAQPage Schema
How do I test internal functions in OpenZeppelin contracts?▼

Use the $-prefixed wrapper contracts auto-generated by hardhat-exposed, which re-expose every internal _function as an external $_function. Deploy them directly with ethers.deployContract('$ERC20', ...) and never write these wrappers by hand.

When should I write a manual mock instead of using hardhat-exposed?▼

Write a manual mock in contracts/mocks/ only for constructor-level setup, multi-extension composition, injected or adversarial behavior like reentrancy, or plain public wrappers where the auto-generated signature is unsuitable. Otherwise prefer the auto-generated $_ functions.

Foundry fuzz vs Halmos symbolic execution for Solidity testing?▼

Foundry fuzzing suits math-heavy code and complex invariants using random inputs, while Halmos treats inputs as fully symbolic for stronger guarantees. Name Halmos tests with a symbolic or testSymbolic prefix so the CI job matches them; they also run as regular fuzz tests.

Why does loadFixture re-run my fixture on every test?▼

loadFixture keys its snapshot cache on the function reference, so an inline anonymous arrow function creates a new reference each call and re-executes. Declare the fixture as a named function and pass that reference instead.

When is Certora formal verification required for a contract change?▼

Use Certora when a contract has a state machine or access-control rules too complex for fuzzing to cover, or when a property exceeds what Halmos can express. Specs live in fv/specs/ and CI runs them on PRs labeled formal-verification.

Does every pull request need a changeset?▼

Every PR that changes contract behavior needs a changeset created with npx changeset add. Skip it for NatSpec-only edits, internal refactors with no user-visible effect, or pure repository plumbing.