- Home
- Skills
- Ed3dai
- Ed3d Plugins
- Property Based Testing
property-based-testing_skill
- Python
128
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill ed3dai/ed3d-plugins --skill property-based-testing- SKILL.md5.2 KB
Overview
This skill helps you apply property-based testing (PBT) when writing tests for serialization, validation, normalization, and pure functions. It provides a compact property catalog, pattern detection guidance, library references, and practical input and settings best practices. Use it to find the strongest meaningful properties and avoid common PBT pitfalls.
How this skill works
The skill inspects function signatures, naming patterns (encode/decode, normalize, sort, validate), and test intent to recommend appropriate properties (roundtrip, idempotence, invariant, commutativity, etc.). It suggests input strategies, Hypothesis/fast-check snippets, and test settings for development, CI, and nightly runs. It flags red flags like tautological assertions, vacuous tests, overuse of assume(), and accidental reimplementation.
When to use it
- Testing serialization/deserialization or encode/decode pairs (roundtrip)
- Verifying normalizers, sanitizers, or canonicalizers (idempotence)
- Checking pure functions with algebraic contracts (commutativity, associativity)
- Validating validators/normalizers where output must satisfy an invariant
- Testing data structure operations (add/remove/get invariants)
Best practices
- Constrain inputs in the strategy, avoid heavy use of assume()
- Limit sizes (max_size, max_length) to prevent slow tests
- Reuse shared strategies for consistent, maintainable tests
- Prefer the strongest applicable property (roundtrip > idempotence)
- Add explicit edge-case @example tests alongside generated cases
Example use cases
- Roundtrip test for JSON: decode(encode(x)) == x for domain types
- Idempotence for a normalize() function: normalize(normalize(x)) == normalize(x)
- Invariant for collections: remove(add(coll, x), x) leaves coll unchanged
- Oracle test: new_impl(x) == reference_impl(x) across generated inputs
- No-crash baseline for inputs that must never raise exceptions
FAQ
Avoid PBT for simple CRUD with no transformation logic, UI rendering, integration tests with complex external setup, or highly stateful code you cannot isolate.
How do I avoid flaky or vacuous PBT tests?
Build constraints into strategies instead of using assume(), keep realistic data ranges and sizes, and include explicit examples for edge cases so tests are meaningful.