🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🎲 धडा 09 — Property-based testing: एक नियम, एक seed आणि shrinking

📍 तुम्ही इथे आहात: 12 पैकी धडा 09 · मागील: lesson-08-e2e-pyramid · पुढील: lesson-10-coverage-mutation

📦 या ब्रँचमध्ये काय आहे

धडे 01–08, आणि त्याशिवाय property-based testing: प्रत्येक प्रश्न स्वतः निवडण्याऐवजी तुम्ही प्रत्येक input साठी खरा असायलाच हवा असा नियम (एक property) सांगता, एका seeded generator ला शंभर inputs तयार करू देता, आणि एखादा fail झाला की त्याला अजून fail होणाऱ्या सोप्या input पर्यंत shrink करता. Rng, forall() आणि shrink() exam/lab.py मध्ये; property exam/demo.py मध्ये.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

एकेक प्रश्न लिहून कतरिना कंटाळली आहे. म्हणून ती त्याऐवजी एक नियम लिहून ठेवते:

".5 ने संपणाऱ्या गुणाला पुढच्या पूर्ण संख्येइतकाच तोच grade मिळायला हवा." (कारण अर्धे गुण वर round होतात.)

मग ती तो नियम एका प्रश्न-यंत्राकडे 🎲 देते. यंत्र एक पूर्ण संख्या n निवडते — 0 ते 99 मधली कोणतीही — आणि तपासते: n + 0.5 ला n + 1 इतकाच grade मिळतो का? हे ते 100 वेळा करते.

9व्या प्रयत्नात ते 74 निवडते: 74.5 ला B मिळतो, पण 75 ला A. नियम मोडला! 🚨

आता यंत्र एक हुशार गोष्ट करते. ते विचारते: "नियम मोडणारी अजून सोपी संख्या आहे का?" ते 0 वापरून पाहते, मग 74 चा अर्धा, मग 64, 54, 44 — तीही मोडते! मग 44 पासून: 0, 22, 34 — तीही मोडते! 34 पासून त्याहून लहान कोणतीच संख्या नियम मोडत नाही. म्हणून यंत्र त्याला सापडलेले सर्वात सोपे failure सांगते: 34.5. धडा 03 मधलाच bug, कतरिनाने एकही score न निवडता सापडलेला.

यंत्र आपला seed — त्याच्या फाशांचा सुरुवातीचा आकडा — सुद्धा लिहून ठेवते, म्हणजे कोणालाही नेमके तेच 100 प्रश्न पुन्हा चालवता येतात.

🗺️ आकृती

flowchart LR
    r["📜 property<br/>grade(n + 0.5) == grade(n + 1)"] --> g["🎲 seeded generator<br/>seed 3, n in 0..99"]
    g --> run["run 1..100"]
    run -->|"run 9: n = 74"| f["❌ 74.5 → B but 75 → A"]
    f --> s["🔍 shrink<br/>74 → 44 → 34"]
    s --> m["smallest failing score 34.5"]

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/testing/lesson-diagrams.html#l09

❓ काय

Example-based test — input आणि अपेक्षित output तुम्ही निवडता (धडे 02–03).
Property — सर्व वैध inputs साठी खरे असणारे विधान. नेहमीचे प्रकार:
- invariants — "average सर्वात कमी आणि सर्वात जास्त mark यांच्यामध्येच असते"
- inputs मधील संबंध (metamorphic) — "x.5 ला x + 1 इतकाच grade मिळतो"; "जास्त score ला कधीच कमी grade मिळत नाही"
- round trips — decode(encode(x)) == x
- oracle — एका साध्या, हळू, उघडपणे बरोबर असलेल्या version शी तुलना करणे
Generator (strategy) — random वैध inputs तयार करतो. चांगले generators कडेच्या values (0, रिकामे, कमाल) निव्वळ योगायोगापेक्षा जास्त वेळा देतात.
Seed — pseudo-random generator ची सुरुवातीची value. तोच seed, तेच inputs: failure पुन्हा चालवता येते.
Shrinking — failure नंतर सोपे inputs (लहान संख्या, छोट्या lists) वापरून पाहणे आणि जे अजूनही fail होतात ते ठेवणे. निकाल म्हणजे स्थानिक पातळीवर सर्वात सोपा failing case — random input पेक्षा debug करायला सहसा खूपच सोपा. तो शक्य तितका सर्वात लहान असेलच याची खात्री नाही.
QuickCheck — मूळ property-based testing tool (Koen Claessen आणि John Hughes, Haskell, 2000). Python साठी Hypothesis आहे.

🤔 का

कारण तुम्हाला सुचणारे प्रश्न काय चुकू शकते याच्या तुमच्या कल्पनेपुरतेच मर्यादित असतात. Property नियम एकदा सांगते, आणि यंत्र तो मोडणारे inputs शोधते — ज्यात कोणीही हाताने निवडणार नाही असे inputs सुद्धा असतात. स्पष्ट नियम आणि प्रचंड input space असलेल्या code वर ते सर्वात प्रभावी असते: parsers, serializers, पैसे आणि rounding, sorting, तारखांचे गणित.

🔧 कसे (या repo मध्ये)

exam/lab.py मधील Rng(seed) हा एक छोटा linear congruential generator आहे; rng.int(lo, hi) lo ते hi मधली पूर्ण संख्या देतो. forall(prop, gen, runs, seed) gen(rng) वापरून runs inputs काढते; ज्या पहिल्या input वर prop(x) false येते, तिथे ते shrink(prop, x) बोलवते आणि run क्रमांक, failing input, shrink केलेला input आणि पायऱ्या परत देते. shrink आधी 0, n // 2, मग n − 10, n − 20, …, आणि n − 1 वापरून पाहते, अजूनही fail होणारा पहिला उमेदवार ठेवते, आणि कोणताच fail होत नाही तोपर्यंत हे पुन्हा पुन्हा करते.

🧪 करून पाहा

python3 exam/demo.py property
python3 - <<'EOF'
from exam.lab import forall, shrink, Rng
from exam.grades import grade, grade_v1, report_card
prop = lambda n: grade_v1(n + 0.5) == grade_v1(n + 1)
for seed in (1, 2, 3, 6, 9):
    i, x, small, steps = forall(prop, lambda r: r.int(0, 99), runs=100, seed=seed)
    print(f"seed {seed}: first failure on run {i:>2} at n={x} · shrink path {steps}")
print("shrink from 74 by hand:", shrink(prop, 74))
avg_between = lambda rng: (lambda ms: min(ms) <= report_card("x", dict(enumerate(ms)), 90)["average"] <= max(ms))([rng.int(0, 100) for _ in range(rng.int(1, 6))])
i, x, _, _ = forall(lambda seed: avg_between(Rng(seed)), lambda r: r.int(1, 10**6), runs=200, seed=5)
print(f"'the average lies between the lowest and highest mark': {i} runs, failures {x}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

property हे छापते:

   grade_v1, seed 1: fails on run 25 at n=34 (34.5) · shrinks 34 → smallest failing score 34.5
   grade_v1, seed 3: fails on run 9 at n=74 (74.5) · shrinks 74 → 44 → 34 → smallest failing score 34.5
   grade (fixed), seed 1: 100 runs, failures: None
   grade_v1 property 'a higher score never gets a lower grade', 300 runs → failures: None

तुमचा snippet हे छापतो:

seed 1: first failure on run 25 at n=34 · shrink path [34]
seed 2: first failure on run 47 at n=34 · shrink path [34]
seed 3: first failure on run  9 at n=74 · shrink path [74, 44, 34]
seed 6: first failure on run  6 at n=44 · shrink path [44, 34]
seed 9: first failure on run  2 at n=34 · shrink path [34]
shrink from 74 by hand: (34, [74, 44, 34])
'the average lies between the lowest and highest mark': 200 runs, failures None

🏁 तुम्ही आत्ताच काय सिद्ध केले

पाच वेगवेगळ्या seeds ना bug वेगवेगळ्या runs मध्ये आणि वेगवेगळ्या scores वर सापडला, आणि shrinking ने त्या प्रत्येकाला एकाच सोप्या case पर्यंत आणले, 34.5. दुरुस्त grade 100 runs pass झाले. पण demo मधली दुसरी property पाहा: "जास्त score ला कधीच कमी grade मिळत नाही" ही bug असलेल्या grade_v1 साठीही pass झाली — score वाढल्यावर round() कधीच खाली जात नाही. Property फक्त तेच शोधते जे ती सांगते. आणि 100 pass झालेले runs म्हणजे 100 उदाहरणे, सिद्धता नव्हे; दुर्दैवी seed आणि थोडे runs असतील तर bug लपून राहू शकतो.

⚠️ नेहमीच्या चुका

test होणारा code पुन्हा तसाच लिहिणाऱ्या properties (त्यांच्यात त्याचेच bugs येतात)
failure report मध्ये seed नसणे, त्यामुळे failure पुन्हा चालवता येत नाही
कडेच्या values (रिकाम्या lists, 0, अर्धे गुण, खूप मोठ्या values) कधीच न देणारे generators
सापडलेले failure fixed example test म्हणून जोडण्याऐवजी फेकून देणे
"100 runs pass झाले" म्हणजे "बरोबर असल्याचे सिद्ध झाले" असे समजणे

🏭 प्रत्यक्ष वापरात

खऱ्या project मध्ये — तीच property Hypothesis मध्ये (pip install hypothesis), pytest ने चालवलेली:

from hypothesis import given, example, strategies as st
from exam.grades import grade

@given(st.integers(min_value=0, max_value=99))
@example(34)                                   # always also try the case that bit us once
def test_half_marks_round_up(n):
    assert grade(n + 0.5) == grade(n + 1)

grade_v1 वर चालवल्यावर Hypothesis shrink केलेला input सांगते:

Falsifying example: test_half_marks_round_up(
    n=34,
)

Hypothesis failing examples स्थानिक .hypothesis/ directory मध्ये साठवते आणि पुढच्या run मध्ये ते आधी वापरून पाहते; @settings(max_examples=500) जास्त examples मागते, आणि @seed(1234) randomness पक्की करते. इतर ecosystems: QuickCheck (Haskell), fast-check (JavaScript/TypeScript), jqwik (Java), proptest (Rust).

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: असे एक function शोधा ज्याचा नियम तुम्ही एका वाक्यात सांगू शकता — serializer (round trip), किंमतीचे गणित (कधीच negative नाही), sort (output क्रमाने आहे आणि त्यात तेच items आहेत). ती property आधी लिहा; हाताने निवडलेली उदाहरणेही ठेवा.

⏭️ पुढे

Test suite किती चांगला आहे? "कोणत्या lines चालल्या?" हे नेहमीचे उत्तर — coverage. Mutation testing एक कठीण प्रश्न विचारते: code चुकीचा असता तर कोणत्या test ला ते लक्षात आले असते का?

git checkout lesson-10-coverage-mutation

🎲 Lesson 09 — Property-based testing: a rule, a seed and shrinking

📍 You are here: Lesson 09 of 12 · Previous: lesson-08-e2e-pyramid · Next: lesson-10-coverage-mutation

📦 What's in this branch

Lessons 01–08, plus property-based testing: instead of choosing each question, you state a rule that must hold for every input (a property), let a seeded generator invent a hundred inputs, and when one fails, shrink it to a simpler failing input. Rng, forall() and shrink() in exam/lab.py; property in exam/demo.py.

🧒 Explain like I'm 5

Katrina is tired of writing questions one by one. So she writes down a rule instead:

"A score ending in .5 must get the same grade as the next whole number." (Because halves round up.)

Then she hands the rule to a question machine 🎲. The machine picks a whole number n — any from 0 to 99 — and checks: does n + 0.5 get the same grade as n + 1? It does this 100 times.

On the 9th try it picks 74: 74.5 gets B, but 75 gets A. Rule broken! 🚨

Now the machine does something clever. It asks: "Is there a simpler number that also breaks the rule?" It tries 0, then half of 74, then 64, 54, 44 — broken too! Then from 44: 0, 22, 34 — broken too! From 34 nothing smaller breaks it. So the machine reports the simplest failure it found: 34.5. The same bug from lesson 03, found without Katrina choosing a single score.

The machine also writes down its seed — the starting number of its dice — so anybody can replay exactly the same 100 questions.

🗺️ Diagram

flowchart LR
    r["📜 property<br/>grade(n + 0.5) == grade(n + 1)"] --> g["🎲 seeded generator<br/>seed 3, n in 0..99"]
    g --> run["run 1..100"]
    run -->|"run 9: n = 74"| f["❌ 74.5 → B but 75 → A"]
    f --> s["🔍 shrink<br/>74 → 44 → 34"]
    s --> m["smallest failing score 34.5"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/testing/lesson-diagrams.html#l09

❓ What

Example-based test — you pick the input and the expected output (lessons 02–03).
Property — a statement true for all valid inputs. Common kinds:
- invariants — "the average lies between the lowest and highest mark"
- relations between inputs (metamorphic) — "x.5 gets the same grade as x + 1"; "a higher score never gets a lower grade"
- round trips — decode(encode(x)) == x
- an oracle — compare with a simple, slow, obviously correct version
Generator (strategy) — produces random valid inputs. Good generators favour edge values (0, empty, the maximum) more often than pure chance would.
Seed — the starting value of the pseudo-random generator. Same seed, same inputs: a failure can be replayed.
Shrinking — after a failure, try simpler inputs (smaller numbers, shorter lists) and keep any that still fail. The result is a locally simplest failing case — usually far easier to debug than the random one. It is not guaranteed to be the smallest possible.
QuickCheck — the original property-based testing tool (Koen Claessen and John Hughes, Haskell, 2000). Hypothesis is the Python one.

🤔 Why

Because the questions you think of are limited by what you already imagine can go wrong. A property states the rule once, and the machine searches for inputs that break it — including ones nobody would pick by hand. It is strongest on code with a clear rule and a huge input space: parsers, serializers, money and rounding, sorting, date arithmetic.

🔧 How (in this repo)

Rng(seed) in exam/lab.py is a small linear congruential generator; rng.int(lo, hi) gives a whole number from lo to hi. forall(prop, gen, runs, seed) draws runs inputs with gen(rng); on the first input where prop(x) is false it calls shrink(prop, x) and returns the run number, the failing input, the shrunk input and the steps. shrink tries 0, n // 2, then n − 10, n − 20, …, and n − 1, keeps the first candidate that still fails, and repeats until none does.

🧪 Try it

python3 exam/demo.py property
python3 - <<'EOF'
from exam.lab import forall, shrink, Rng
from exam.grades import grade, grade_v1, report_card
prop = lambda n: grade_v1(n + 0.5) == grade_v1(n + 1)
for seed in (1, 2, 3, 6, 9):
    i, x, small, steps = forall(prop, lambda r: r.int(0, 99), runs=100, seed=seed)
    print(f"seed {seed}: first failure on run {i:>2} at n={x} · shrink path {steps}")
print("shrink from 74 by hand:", shrink(prop, 74))
avg_between = lambda rng: (lambda ms: min(ms) <= report_card("x", dict(enumerate(ms)), 90)["average"] <= max(ms))([rng.int(0, 100) for _ in range(rng.int(1, 6))])
i, x, _, _ = forall(lambda seed: avg_between(Rng(seed)), lambda r: r.int(1, 10**6), runs=200, seed=5)
print(f"'the average lies between the lowest and highest mark': {i} runs, failures {x}")
EOF

✅ Verify — what you should see

property prints:

   grade_v1, seed 1: fails on run 25 at n=34 (34.5) · shrinks 34 → smallest failing score 34.5
   grade_v1, seed 3: fails on run 9 at n=74 (74.5) · shrinks 74 → 44 → 34 → smallest failing score 34.5
   grade (fixed), seed 1: 100 runs, failures: None
   grade_v1 property 'a higher score never gets a lower grade', 300 runs → failures: None

Your snippet prints:

seed 1: first failure on run 25 at n=34 · shrink path [34]
seed 2: first failure on run 47 at n=34 · shrink path [34]
seed 3: first failure on run  9 at n=74 · shrink path [74, 44, 34]
seed 6: first failure on run  6 at n=44 · shrink path [44, 34]
seed 9: first failure on run  2 at n=34 · shrink path [34]
shrink from 74 by hand: (34, [74, 44, 34])
'the average lies between the lowest and highest mark': 200 runs, failures None

🏁 What you just proved

Five different seeds hit the bug at different runs and different scores, and shrinking took every one of them to the same simple case, 34.5. The fixed grade passed 100 runs. But look at the second property in the demo: "a higher score never gets a lower grade" passed for the buggy grade_v1 too — round() never goes down as the score goes up. A property finds only what it states. And 100 passing runs are 100 examples, not a proof; with an unlucky seed and few runs, the bug could hide.

⚠️ Common mistakes

properties that re-implement the code under test (they share its bugs)
no seed in the failure report, so the failure cannot be replayed
generators that never produce the edges (empty lists, 0, halves, very large values)
throwing away a found failure instead of adding it as a fixed example test
reading "100 runs passed" as "proved correct"

🏭 In production

On a real project — the same property in Hypothesis (pip install hypothesis), run by pytest:

from hypothesis import given, example, strategies as st
from exam.grades import grade

@given(st.integers(min_value=0, max_value=99))
@example(34)                                   # always also try the case that bit us once
def test_half_marks_round_up(n):
    assert grade(n + 0.5) == grade(n + 1)

Run against grade_v1, Hypothesis reports the shrunk input:

Falsifying example: test_half_marks_round_up(
    n=34,
)

Hypothesis stores failing examples in a local .hypothesis/ directory and tries them first on the next run; @settings(max_examples=500) asks for more examples, and @seed(1234) pins the randomness. Other ecosystems: QuickCheck (Haskell), fast-check (JavaScript/TypeScript), jqwik (Java), proptest (Rust).

🏭 Why this matters in production: find one function where you can state a rule in a sentence — a serializer (round trip), a price calculation (never negative), a sort (output is ordered and has the same items). Write that property first; keep your hand-picked examples too.

⏭️ Next

How good is a test suite? "Which lines ran?" is the usual answer — coverage. Mutation testing asks a harder question: would any test notice if the code were wrong?

git checkout lesson-10-coverage-mutation

← Previouse2e pyramid Next →coverage mutation

This page is the lesson's README from the lesson-09-property-based branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.