- Home
- Skills
- Multiversx
- Mx Ai Skills
- Mvx Property Testing
mvx_property_testing_skill
10
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 multiversx/mx-ai-skills --skill mvx_property_testing- SKILL.md927 B
Overview
This skill teaches how to apply property-based testing and fuzzing to Rust smart contracts to surface edge cases and invariant violations. It focuses on defining clear invariants for contract state and exercising contract logic with randomized inputs. The goal is faster detection of logic bugs and safer contract behavior before deployment.
How this skill works
You define invariants that must always hold for contract state, then use fuzzing and property testing to generate wide ranges of inputs. Tests execute contract operations in a mocked blockchain environment and assert invariants after each scenario. Failures reveal minimal counterexamples that can be reproduced, diagnosed, and fixed.
When to use it
- During development of smart contract core logic to catch subtle state bugs early
- Before major releases or audit gates to increase confidence in invariants
- When adding new features that interact with token balances or permissions
- To validate invariants across many edge cases not covered by example-based tests
- When migrating or refactoring contract code to ensure behavior is preserved
Best practices
- Start by writing a small set of high-value invariants (e.g., totalSupply equals sum of balances)
- Keep the mocked blockchain deterministic and reproducible so failures are debuggable
- Limit input domains initially, then expand ranges once tests are stable
- Combine proptest for structured generation with cargo-fuzz for deep fuzz exploration
- Record and minimize failing cases to a small reproducer for root-cause analysis
Example use cases
- Test that deposits never decrease a user balance by fuzzing amounts and user IDs
- Verify total token supply equals aggregated balances after random transfers and mint/burn actions
- Stress-check permission checks by fuzzing caller identities and sequence of calls
- Validate invariants across replayed sequences of operations to find stateful bugs
- Use reduced failing inputs from proptest to craft regression tests and fixes
FAQ
Use proptest for structured property-based tests and cargo-fuzz for aggressive fuzz exploration; they complement each other.
How do I keep tests reproducible when fuzzing?
Seed generators deterministically and log the minimal failing input; ensure the mock blockchain and environment are fully deterministic.
What invariants are most useful for token contracts?
Start with supply-related invariants (total supply vs. balances), non-negative balances, and permission/authorization invariants.