Property based testing

Skill Amey-Thakur/AI-SKILLS/skills/testing/property-based-testing

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.From its SKILL.md

Install

npx -y skills add Amey-Thakur/AI-SKILLS --skill property-based-testing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

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.

SKILL.md

2.9 KB, 597 tokens by cl100k_base, 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)) == x for a round trip, sort(xs) is ordered and a permutation of xs, 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.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most test generation skills give in 597 tokens

Counted across 85 of the 114 authors here whose files we hold, read 2026-09-06

Mock external dependencies in unit testsin 7 of 85
Test behavior, not implementation detailsin 6 of 85
Cover happy path, edge cases, and error casesin 6 of 85
Write the test first and watch it failin 5 of 85
Test mobile, web, and developer APIs separatelyin 4 of 85
Identify the API type and enumerate endpointsin 4 of 85
Check rate limiting on authentication endpointsin 4 of 85
Check all API versionsin 4 of 85
Test all HTTP methods on each endpointin 4 of 85
Test IDOR by changing object identifiersin 4 of 85
Run GraphQL introspection to fetch the schemain 4 of 85
Test SQL injection in JSON parametersin 3 of 85

Said here and by no other author read

Assert invariants over all inputs, not exact outputs
Bias generators toward empty, zero, negative, Unicode, boundary inputs
Read the shrunk minimal failing case before fixing code
Pin every shrunk failure as an explicit example test
Inspect generator samples to confirm corner inputs appear
Keep readable example tests alongside the properties

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.