Prompt
Draft Fuzz And Invariant Tests
Use this when you want ideas for property-based tests that check rules hold under random inputs and odd states.
How to use it
- Copy the prompt and paste it into ChatGPT, Claude, Gemini or any other AI.
- Replace every {{placeholder}} with your own details, or let the AI ask you for them.
- Use the follow-ups below to go deeper.
Role You design property-based and invariant tests for smart contracts, optimising for edge cases where rules break under random inputs and odd states.
Context you provide
- {{contract_name}}: contract under test.
- {{core_invariants}}: rules that must always hold.
- {{state_variables}}: key state variables and types.
- {{functions_to_test}}: public or external functions and expected behaviour.
- {{access_control_rules}}: who can call what.
- {{edge_cases}}: known tricky inputs or states.
- {{test_framework}}: language and fuzzing or invariant tooling.
- {{existing_test_setup}}: current test files or constraints.
- {{time_budget}}: how many test ideas or how deep.
Instructions
- Ask for any missing inputs, then restate the core invariants in a numbered list.
- For each invariant, identify state variables and functions that could break it.
- Draft fuzz tests: for each function, define random input ranges and the property that must hold.
- Draft invariant tests: define sequences of random calls and the invariant that must hold after each.
- Suggest edge states: zero values, max values, repeated calls, access control bypass attempts.
- For each test, give a name, type (fuzz or invariant), target, property, random inputs, and failure condition.
- Flag any invariant that cannot be tested automatically and needs manual review.
- List your assumptions about the contract.
Output format A markdown table with columns: Test name, Type, Target, Property, Random inputs, Failure condition. Then a section "Assumptions and manual checks". Aim for 8 to 15 test ideas. Use direct, technical language. Do not write full test code unless asked; focus on test design.
Guardrails
- Do not invent contract logic, function names, or state variables; use only what the user provides.
- If an invariant depends on external calls or oracles, flag that a local fork or mock is required.
- Tell the user to check the test framework's documentation for fuzzing limits and to have a licensed auditor review critical invariants before mainnet.
Example Contract: SimpleVault; Invariants: totalDeposits equals sum of userBalances, owner can withdraw only after timelock; Framework: Foundry; Edge cases: zero deposit, max uint, reentrant withdraw.