property-based-testing
- Repo stars 5,723
- Forks 499
- Author updated Jun 15, 2026, 04:05 PM
- Author repo skills
- Domain
- Documentation
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @trailofbits · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: property-based-testing
description: Provides guidance for property-based testing across multiple languages and smart contracts. Use…
category: documentation
runtime: no special runtime
---
# property-based-testing output preview
## PART A: Task fit
- Use case: Provides guidance for property-based testing across multiple languages and smart contracts. Use when writing tests, reviewing code with serialization/validation/parsing patterns, designing features, or when property-based testing would provide stronger coverage than example-based tests..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Invoke (Automatic Detection) / When NOT to Use / Property Catalog (Quick Reference)” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Provides guidance for property-based testing across multiple languages and smart contracts. Use when writing tests, reviewing code with serialization/validation/parsing patterns, designing features, or when property-based testing would provide stronger coverage than example-based tests.”.
- **02** When the source has headings, the agent prioritizes “When to Invoke (Automatic Detection) / When NOT to Use / Property Catalog (Quick Reference)” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Validate with a small run
Start with a small task and check whether the result follows “When to Invoke (Automatic Detection) / When NOT to Use / Property Catalog (Quick Reference)”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: property-based-testing
description: Provides guidance for property-based testing across multiple languages and smart contracts. Use…
category: documentation
source: trailofbits/skills
---
# property-based-testing
## When to use
- Provides guidance for property-based testing across multiple languages and smart contracts. Use when writing tests, re…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Invoke (Automatic Detection) / When NOT to Use / Property Catalog (Quick Reference)” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "property-based-testing" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Invoke (Automatic Detection) / When NOT to Use / Property Catalog (Quick Reference)
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Property-Based Testing Guide
Use this skill proactively during development when you encounter patterns where PBT provides stronger coverage than example-based tests.
When to Invoke (Automatic Detection)
Invoke this skill when you detect:
- Serialization pairs:
encode/decode,serialize/deserialize,toJSON/fromJSON,pack/unpack - Parsers: URL parsing, config parsing, protocol parsing, string-to-structured-data
- Normalization:
normalize,sanitize,clean,canonicalize,format - Validators:
is_valid,validate,check_*(especially with normalizers) - Data structures: Custom collections with
add/remove/getoperations - Mathematical/algorithmic: Pure functions, sorting, ordering, comparators
- Smart contracts: Solidity/Vyper contracts, token operations, state invariants, access control
Priority by pattern:
| Pattern | Property | Priority |
|---|---|---|
| encode/decode pair | Roundtrip | HIGH |
| Pure function | Multiple | HIGH |
| Validator | Valid after normalize | MEDIUM |
| Sorting/ordering | Idempotence + ordering | MEDIUM |
| Normalization | Idempotence | MEDIUM |
| Builder/factory | Output invariants | LOW |
| Smart contract | State invariants | HIGH |
When NOT to Use
Do NOT use this skill for:
- Simple CRUD operations without transformation logic
- One-off scripts or throwaway code
- Code with side effects that cannot be isolated (network calls, database writes)
- Tests where specific example cases are sufficient and edge cases are well-understood
- Integration or end-to-end testing (PBT is best for unit/component testing)
Property Catalog (Quick Reference)
| Property | Formula | When to Use |
|---|---|---|
| Roundtrip | decode(encode(x)) == x |
Serialization, conversion pairs |
| Idempotence | f(f(x)) == f(x) |
Normalization, formatting, sorting |
| Invariant | Property holds before/after | Any transformation |
| Commutativity | f(a, b) == f(b, a) |
Binary/set operations |
| Associativity | f(f(a,b), c) == f(a, f(b,c)) |
Combining operations |
| Identity | f(x, identity) == x |
Operations with neutral element |
| Inverse | f(g(x)) == x |
encrypt/decrypt, compress/decompress |
| Oracle | new_impl(x) == reference(x) |
Optimization, refactoring |
| Easy to Verify | is_sorted(sort(x)) |
Complex algorithms |
| No Exception | No crash on valid input | Baseline property |
Strength hierarchy (weakest to strongest): No Exception → Type Preservation → Invariant → Idempotence → Roundtrip
Decision Tree
Based on the current task, read the appropriate section:
TASK: Writing new tests
→ Read [{baseDir}/references/generating.md]({baseDir}/references/generating.md) (test generation patterns and examples)
→ Then [{baseDir}/references/strategies.md]({baseDir}/references/strategies.md) if input generation is complex
TASK: Designing a new feature
→ Read [{baseDir}/references/design.md]({baseDir}/references/design.md) (Property-Driven Development approach)
TASK: Code is difficult to test (mixed I/O, missing inverses)
→ Read [{baseDir}/references/refactoring.md]({baseDir}/references/refactoring.md) (refactoring patterns for testability)
TASK: Reviewing existing PBT tests
→ Read [{baseDir}/references/reviewing.md]({baseDir}/references/reviewing.md) (quality checklist and anti-patterns)
TASK: Test failed, need to interpret
→ Read [{baseDir}/references/interpreting-failures.md]({baseDir}/references/interpreting-failures.md) (failure analysis and bug classification)
TASK: Need library reference
→ Read [{baseDir}/references/libraries.md]({baseDir}/references/libraries.md) (PBT libraries by language, includes smart contract tools)How to Suggest PBT
When you detect a high-value pattern while writing tests, offer PBT as an option:
"I notice
encode_message/decode_messageis a serialization pair. Property-based testing with a roundtrip property would provide stronger coverage than example tests. Want me to use that approach?"
If codebase already uses a PBT library (Hypothesis, fast-check, proptest, Echidna), be more direct:
"This codebase uses Hypothesis. I'll write property-based tests for this serialization pair using a roundtrip property."
If user declines, write good example-based tests without further prompting.
When NOT to Use PBT
- Simple CRUD without complex validation
- UI/presentation logic
- Integration tests requiring complex external setup
- Prototyping where requirements are fluid
- User explicitly requests example-based tests only
Red Flags
- Recommending trivial getters/setters
- Missing paired operations (encode without decode)
- Ignoring type hints (well-typed = easier to test)
- Overwhelming user with candidates (limit to top 5-10)
- Being pushy after user declines
Rationalizations to Reject
Do not accept these shortcuts:
- "Example tests are good enough" - If serialization/parsing/normalization is involved, PBT finds edge cases examples miss
- "The function is simple" - Simple functions with complex input domains (strings, floats, nested structures) benefit most from PBT
- "We don't have time" - PBT tests are often shorter than comprehensive example suites
- "It's too hard to write generators" - Most PBT libraries have excellent built-in strategies; custom generators are rarely needed
- "The test failed, so it's a bug" - Failures require validation; see interpreting-failures.md
- "No crash means it works" - "No exception" is the weakest property; always push for stronger guarantees
Decide Fit First
Design Intent
How To Use It
Boundaries And Review