📝 शाळेच्या पद्धतीने software testing शिका

# the 60-second wow — one grading module, twelve ways to test it:
git clone https://github.com/BaluRaut/learn-testing-school.git && cd learn-testing-school
python3 exam/demo.py               # 12 lessons: a rounding bug, a lying stub, 10 mutants, a wobbly clock
python3 exam/test_exam.py          # 12 checks across the lessons

तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):

═══ why ═══
── Dipika's grade_v1 sits 5 easy exam questions: 5/5 correct — and it still has a bug
   the whole school sits a paper out of 200 (1200 students): 15 report cards get the wrong grade
   wrong scores: [34.5, 44.5, 74.5] · 5 students told they FAILED at 34.5
   found by one test at Dipika's desk: 1 failing check, 0 students hurt · found after the cards are posted:
   15 reprints, 5 apology letters, a re-marking meeting — the later a bug is found, the more it costs
   a passing test proves the code works for THAT input; it cannot prove there is no bug (5/5 passed above)

═══ unit ═══
── the tiny runner: 4 exam questions for grade_v1 (arrange · act · assert)
   distinction            pass
   fail_below_pass_mark   pass
   just_a_distinction     FAIL — expected 'A', got 'B'
   out_of_range           ERROR — ValueError: score out of range: 101
   2 passed, 2 failed · a FAIL is a wrong answer, an ERROR is a crash the test did not expect
── stdlib unittest runs exam/suites/test_grades_unittest.py against grade(): 6 tests · 0 failures · 0 errors
   same shape, more help: setUp/tearDown, assertEqual/assertRaises, discovery, -v; pytest is the popular third-party runner

═══ design ═══
── equivalence classes: one question per class is enough to start
     -5 → refused     20 → F     40 → D     50 → C     65 → B     90 → A    150 → refused
── boundary values: v1 vs the fixed grade()
    34.4: v1 F · fixed F
    34.5: v1 F · fixed D   ← BUG
      35: v1 D · fixed D
    44.5: v1 D · fixed C   ← BUG
      45: v1 C · fixed C
    59.5: v1 B · fixed B
      60: v1 B · fixed B
    74.4: v1 B · fixed B
    74.5: v1 B · fixed A   ← BUG
      75: v1 A · fixed A
   every half-mark 0–100 (201 scores): v1 is wrong at [34.5, 44.5, 74.5] — round() sends halves to the EVEN number
── decision table: promoted = average passes AND (attendance ≥ 75% OR a medical note)
   average 70 · attendance 90% · note no  → promoted
   average 70 · attendance 90% · note yes → promoted
   average 70 · attendance 60% · note no  → held back
   average 70 · attendance 60% · note yes → promoted
   average 30 · attendance 90% · note no  → held back
   average 30 · attendance 90% · note yes → held back
   average 30 · attendance 60% · note no  → held back
   average 30 · attendance 60% · note yes → held back
   3 conditions → 8 rules → 8 tests; a table shows the rule nobody wrote down

═══ fixtures ═══
── a_student() — a prepared answer sheet with sensible defaults → Katrina · average 75.0 · A · promoted True
   .with_attendance(60) → promoted False · + .with_medical_note() → promoted True
   .named('Dipika').with_marks(maths=20, science=30, english=40) → average 30.0 · F
── one SHARED answer sheet: order enrol→empty: 1 passed, 1 failed · order empty→enrol: 2 passed, 0 failed
   a FRESH sheet per test (setup): 2 passed, 0 failed · reversed: 2 passed, 0 failed · teardown ran 2 times
   independent tests pass in any order, alone or together — the order must never be part of the answer

═══ doubles ═══
── the attendance service is far away; stand-in examiners take its place
   stub  (canned answer)      → attendance 86.0% · eligible True
   fake  (a small working one) → student 42: 86.0% · student 7: 70.0% · eligible False
   spy   (records calls)      → calls ['/attendance/42']
   mock  (unittest.mock)      → a 503 raises AttendanceUnavailable; assert_called_once_with('/attendance/42') holds
── over-mocking: the client now asks '/attendance/42?term=1' — same answers, new URL
   fake-based test: eligible True → passes · mock-based test → FAILS (the mock checked HOW, not WHAT)
   and a stub can lie: it returned {'days_present': ...} but what if the real service says 'present'? → KeyError 'days_present' in production
   double what you do not own or cannot run fast; check the doubles against the real thing (lesson 07)

═══ integration ═══
── Katrina 68 and Dipika 67 in maths; the class average should be 67.5
   unit test with a Python fake store → 67.5 ✅ (Python's / keeps the half)
   integration test, REAL SQLite in memory, v1 SQL SUM/COUNT → 67 ❌ (INTEGER / INTEGER drops it)
   fixed SQL AVG(marks) → 67.5 ✅
   save Katrina's maths twice: fake silently overwrites · SQLite → IntegrityError (the PRIMARY KEY the fake never had)
── exam/suites/test_store_sqlite.py: 3 tests · 0 failing · a fresh :memory: database per test
   integration tests catch the bugs that live BETWEEN your code and the real thing: SQL, types, constraints

═══ contract ═══
── the consumer (report cards) writes down what it needs: GET /attendance/42 → 200 with days_present:int, days_total:int
   provider v1 as today                  → ✅ honours the contract
   provider v2 adds 'late_days'          → ✅ honours the contract
   provider v3 renames to 'present'      → ❌ missing field 'days_present'
   provider v4 sends days_total as text  → ❌ 'days_total' is str, expected int
   the provider runs the consumer's contract in ITS pipeline — v3 and v4 are stopped before they ship
   a new field is fine (the consumer ignores what it did not ask for); renames and type changes are not

═══ pyramid ═══
── one end-to-end run through the teaching app: database → attendance → report card → Aishwarya: average 74.33 · B · attendance 86.0% · promoted True
── a cost MODEL (illustrative numbers): unit 0.005 s, integration 0.1 s, e2e 5 s per test; flake chance 0.01% / 0.05% / 1%
   pyramid         400 / 80 / 10 tests →   60.0 s per run · a run hits at least one flaky failure 17% of the time
   trophy          150 / 300 / 10 tests →   80.8 s per run · a run hits at least one flaky failure 23% of the time
   ice-cream cone  50 / 50 / 200 tests → 1005.2 s per run · a run hits at least one flaky failure 87% of the time
   both good shapes keep e2e tests FEW; they disagree on whether most tests are unit or integration

═══ property ═══
── property: for every whole n from 0 to 99, grade(n + 0.5) == grade(n + 1) — halves round UP
   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
   grade    property 'a higher score never gets a lower grade', 300 runs → failures: None
   grade_v1 passes the second property — round() never goes DOWN as the score goes up; a property finds only what it states
   the seed is printed so a failure can be replayed; shrinking hands you a simpler failing case than the first one found

═══ mutation ═══
── WEAK suite (7 questions): line coverage of grade() 12/12 = 100% · mutants killed 4/10
   s >= 75               → s > 75         SURVIVED
   s >= 35               → s > 35         SURVIVED
   s >= 60               → s >= 61        SURVIVED
   round_half_up(score)  → round(score)   SURVIVED
   return "A"            → return "B"     killed
   return "F"            → return "D"     killed
   score < 0 or          → score < 0 and  killed
   s >= 45               → s <= 45        killed
   score > 100           → score > 101    SURVIVED
   s >= 75               → s > 74         SURVIVED
── STRONG suite (21 questions): line coverage of grade() 12/12 = 100% · mutants killed 9/10
   the survivor of the STRONG suite: 's >= 75' → 's > 74' — s is a whole number, so this mutant is EQUIVALENT (no test can kill it)
   coverage says which lines RAN; mutation testing asks whether any test would NOTICE if they were wrong

═══ flaky ═══
── the wobbly clock on the wall: run each test 1000 times with NO code change
   time: due today, handed in within the hour    passed  967 · failed  33 → reads the real clock (fails after 23:00)
   randomness: 3 unseeded scores, one passes     passed  964 · failed  36 → unseeded random data
   waiting: sleep 200 ms, then check the job     passed  924 · failed  76 → a fixed sleep instead of waiting for done
   order: shared ROLL list, all 6 orders of 3 tests → 5 orders fail · fresh ROLL per test → 0 fail
── fixed: an injected clock → passed 1000, failed 0 · a seed → the same 3 scores every run · wait for 'done', not for time
   a test that both passes and fails on the same code is flaky — quarantine it, find the variable, pin it down

═══ ci ═══
── TDD for a new rule: a student 2 marks short of 35 WITH a medical note is lifted to 35
   RED      (test first, no code)  → 0/5 pass
   GREEN    (simplest code)        → 5/5 pass
   REFACTOR (name the rule)        → 5/5 pass
── test selection: a change to the attendance client
   runs 3 of 6 suites, 28 of 105 tests: unit/test_attendance, contract/test_attendance_pact, e2e/test_report_flow
   a change to grade() runs 69 of 105 tests · merging to main still runs all 105
   CI order: lint → unit → integration → contract → e2e — fast checks first, stop at the first red
── the whole picture: questions (unit) → the right questions (design) → fresh sheets (fixtures) → stand-ins (doubles) → real database (integration) → promises (contracts) → the pyramid → properties → mutants → a steady clock → CI

✅ done — every paper marked

🗺️ संपूर्ण चित्र — एक आकृती, पूर्ण कोर्स

संपूर्ण कोर्स एका कॅनव्हासवर. 4K आवृत्तीसाठी क्लिक करा.

📝 भाग 1 — मूलभूत गोष्टी (धडे 1–4)

एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. exam/ ची प्रत्येक run सारखीच असते — randomness ला seed दिलेला आहे.

🧑‍🏫 भाग 2 — एका unit च्या पलीकडे (धडे 5–8)

जेव्हा code इतर गोष्टींशी बोलतो: doubles, खरा database, teams मधील contracts, आणि प्रत्येक प्रकारचे किती tests.

🔬 भाग 3 — tests किती चांगले आहेत (धडे 9–12)

tests चीच परीक्षा: generate केलेले inputs, mutants, flakiness — आणि योग्य वेळी योग्य tests चालवणे.

📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा

प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.