Property based testing
Skill Amey-Thakur/AI-SKILLS/skills/testing/property-based-testing
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill property-based-testingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate many inputs to test invariants that must hold across a whole domain, and let shrinking reduce failures to a minimal case. Use when a rule should hold for all inputs, not just the few examples you would think to write.
SKILL.md
2.9 KB, as published. Nobody here has run it
Property-based testing
Example tests check the cases you thought of. Property-based testing checks the ones you did not: a framework generates hundreds of inputs and asserts a property that must hold for every one. It is how you surface the empty string, the max integer, the surrogate-pair character, and the leap second that break code passing all your hand-picked examples. The work is stating properties worth checking and writing generators that reach the interesting inputs.
Method
- Assert invariants, not specific outputs. Strong properties are
relations true for all inputs:
decode(encode(x)) == xfor a round trip,sort(xs)is ordered and a permutation ofxs, output never exceeds a bound. You rarely predict the exact result, you constrain it. - Reach for known property shapes. Round trip, invariant preservation,
a comparison against a slow but obvious oracle, and idempotence
(
f(f(x)) == f(x)) cover most cases. Pick the shape before you write the generator. - Write generators that hit the corners. Use Hypothesis, fast-check, or QuickCheck to build inputs, and bias them toward zero, empty, negatives, Unicode, and boundary sizes. A generator that only makes tidy medium values tests nothing your examples missed.
- Trust shrinking, then read the minimal case. On failure the framework
reduces the input to the smallest that still fails,
""or[0, 0]rather than a 300-element mess. That minimal case usually names the bug outright, so read it before touching the code. - Pin every failure as a regression example. The framework records the failing seed, but also add the shrunk input as an explicit example test so the exact case stays covered after you fix it and the generator moves on.
- Constrain to the valid domain, not past it. Filter or construct inputs
to the precondition with
assume(n > 0)or a positive-int generator. Over-wide generators either drown in discards or test behavior the function never promised.
Checks
- Does the property still read as one sentence about all inputs, or is it secretly a single example?
- When it fails, does the shrunk case point at the real bug rather than incidental noise?
- Do the generators actually produce empty, boundary, and out-of-order inputs, confirmed by inspecting a sample?
Boundaries
Properties complement example tests, they do not replace them: keep readable example tests for the documented behaviors and add properties where a rule spans the domain. To grade how strong the resulting tests are, defer to mutation-testing. Generator libraries differ, so follow the project's.