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

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

💸 धडा 01 — Test का करायचे: उशिरा सापडलेल्या bug ची किंमत

📍 तुम्ही इथे आहात: 12 पैकी धडा 01 · पुढे: lesson-02-unit-tests

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

हा संपूर्ण कोर्स एकाच कल्पनेवर आहे: code म्हणजे परीक्षेला बसलेली विद्यार्थिनी, आणि test म्हणजे परीक्षेतला प्रश्न, ज्याचे बरोबर उत्तर आधीच माहीत असते. दीपिकाने शाळेचा grading code लिहिला. मुख्य परीक्षक कतरिनाला 1200 report cards छापण्याच्या आधी कळायला हवे की तो बरोबर आहे का. संपूर्ण कोर्समध्ये तुम्ही वापरणार असलेल्या खऱ्या files:

exam/grades.py — विद्यार्थिनी: शाळेचे grading module (grades, rounding, report cards, एक attendance client, एक छोटा SQLite store)
exam/lab.py — परीक्षा हॉलची साधने, छोट्या deterministic models च्या रूपात (एक छोटा runner, builders, बदली परीक्षक, एक contract checker, एक property tester, coverage, mutants, flaky tests)
exam/demo.py — प्रत्येक धडा एक छोटा program म्हणून (python3 exam/demo.py <section>; sections: why unit design fixtures doubles integration contract pyramid property mutation flaky ci)
exam/test_exam.py — कोर्सचे स्वतःचे 12 checks
demo-output.txt — निरोगी run काय छापते

🎒 सुरू करण्यापूर्वी: तुम्हाला फक्त Python 3 लागेल, बाकी काही नाही — ना pip install, ना network. lab.py मध्ये शिकवण्यासाठीचे models आहेत, खरी साधने नाहीत. Randomness ला seed दिलेला आहे, म्हणून प्रत्येक run तीच गोष्ट छापते. खरी साधने म्हणजे pytest, Hypothesis, Pact, Playwright, coverage.py आणि mutmut; प्रत्येक धडा ती खऱ्या project वर अशा खुणेच्या blocks मध्ये दाखवतो, ज्यांना pip install लागते आणि जे "करून पाहा" चा भाग नाहीत.

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

शाळेचा नियम सोपा आहे: तुमची टक्केवारी पूर्ण संख्येत round केली जाते, अर्धा वर जातो, आणि 35 म्हणजे pass.

दीपिका code लिहिते. कतरिना त्याला पाच सोपे परीक्षेचे प्रश्न विचारते: 90? A. 65? B. 50? C. 40? D. 10? F. पाच पैकी पाच. 🎉

मग संपूर्ण शाळा 200 गुणांचा पेपर देते. 69 गुण मिळालेल्या विद्यार्थिनीला 34.5% मिळतात. नियम सांगतो 34.5 → 35 → pass. दीपिकाचा code म्हणतो F. ❌

का? Python चे round() अर्ध्याला वर round करत नाही. ते अर्ध्याला जवळच्या सम संख्येकडे नेते: round(34.5) म्हणजे 34. सोप्या प्रश्नांनी कधी अर्ध्याबद्दल विचारलेच नाही.

जर कतरिनाला हे दीपिकाच्या डेस्कवरच आणखी एका प्रश्नाने सापडले, तर दुरुस्ती एका ओळीची आहे. पण report cards पाठवले जाईपर्यंत कोणालाच सापडले नाही, तर त्याची किंमत 15 पुनर्छपाई, नापास सांगितलेल्या विद्यार्थिनींना 5 माफीपत्रे, आणि एक meeting. Bug तोच. फरक फक्त एकच — तो कधी सापडला.

🗺️ आकृती

flowchart LR
    code["✍️ Dipika writes grade_v1<br/>round() sends halves to EVEN"]
    easy["📝 5 easy questions<br/>90 65 50 40 10: 5/5 pass"]
    desk["🔍 found at the desk<br/>1 failing check, 0 pupils hurt"]
    late["📬 found after posting<br/>15 wrong cards, 5 told they failed"]
    code --> easy
    easy -->|"one question at 34.5"| desk
    easy -->|"no such question"| late

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

❓ काय

Test — असा code जो दुसरा code निवडलेल्या input ने चालवतो आणि निकाल अपेक्षित उत्तराशी तपासतो. उत्तरसूची जोडलेला परीक्षेचा प्रश्न.
Bug (defect) — code जे करायला हवे त्यापेक्षा वेगळे करतो. इथे: 34.5 ला D ऐवजी F मिळतो.
Specification — "करायला हवे" म्हणजे काय. Test त्याच्या अपेक्षित उत्तराइतकाच बरोबर असतो; इथे "अर्धा वर round होतो" हा शाळेचा नियम म्हणजे spec.
Test काय सिद्ध करतो — की code ने त्या input साठी, त्या दिवशी, त्या setup मध्ये बरोबर उत्तर दिले. त्यापेक्षा जास्त काही नाही.
Test काय सिद्ध करू शकत नाही — की एकही bug नाही. Edsger Dijkstra ने हे असे मांडले (1970): testing bugs असल्याचे दाखवू शकते, नसल्याचे कधीच नाही. grade_v1 5 पैकी 5 pass झाले आणि तरीही 3 scores चुकीचे होते.
उशिरा सापडलेल्या bug ची किंमत — जितक्या उशिरा bug सापडतो तितकी जास्त माणसे आणि जास्त काम त्याला लागते: त्यावर बांधलेला जास्त code, लिहिलेला जास्त data, चुकीचे उत्तर पाहिलेली जास्त माणसे. पुस्तकांत अनेकदा "design मध्ये 1×, production मध्ये 100×" अशी गुणोत्तरे दिली जातात. त्यांना दंतकथा समजा: मूळ data तुटपुंजा आणि वादग्रस्त आहे (Laurent Bossavit चे The Leprechauns of Software Engineering त्यांचा माग काढते). दिशा खरी आहे; नेमके आकडे हा नियम नाही.
Regression — आधी चालणारी गोष्ट एखाद्या बदलानंतर मोडते. Repo मध्ये राहणारा test त्यानंतर कायम त्यापासून रक्षण करतो.

🤔 का

कारण दुसरा पर्याय म्हणजे software वापरणाऱ्या लोकांकडून bugs सापडणे. या कोर्समधला प्रत्येक test हा लवकर विचारलेला प्रश्न आहे — machine कडून, काही सेकंदांत, प्रत्येक वेळी जेव्हा कोणी code बदलतो. Tests मुळे तुम्ही न घाबरता code बदलू शकता: दीपिका rounding दुरुस्त करते तेव्हा 12 checks तिला एका सेकंदात सांगतात की बाकी काही मोडले नाही. आणि test म्हणजे चालवता येणारे documentation: grade(34.5) == "D" हा नियम comment पेक्षा जास्त स्पष्ट सांगते.

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

exam/grades.py मधले grade_v1(score) Python चे round() वापरते. grade(score) हे round_half_up() वापरते, जे Decimal(str(score)) आणि ROUND_HALF_UP ने round करते. exam/demo.py मधले why() grade_v1 ला पाच सोपे प्रश्न विचारते, मग 200 गुणांच्या पेपरवर 1200 विद्यार्थिनींच्या seeded शाळेचे grading करते (म्हणून प्रत्येक score पूर्ण किंवा अर्धा असतो) आणि दुरुस्त grade() पेक्षा किती cards वेगळे येतात ते मोजते.

🧪 करून पाहा

python3 exam/demo.py why
python3 - <<'EOF'
from exam.grades import grade, grade_v1
print("round() on halves:", [round(x) for x in (0.5, 1.5, 2.5, 34.5, 35.5, 74.5)])
for out_of in (100, 200, 40, 80):
    scores = [m * 100 / out_of for m in range(out_of + 1)]
    wrong = [s for s in scores if grade_v1(s) != grade(s)]
    print(f"paper out of {out_of:>3}: {len(scores):>3} possible scores · v1 wrong at {wrong}")
EOF
python3 exam/test_exam.py

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

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

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

round() on halves: [0, 2, 2, 34, 36, 74]
paper out of 100: 101 possible scores · v1 wrong at []
paper out of 200: 201 possible scores · v1 wrong at [34.5, 44.5, 74.5]
paper out of  40:  41 possible scores · v1 wrong at []
paper out of  80:  81 possible scores · v1 wrong at []

Checks शेवटी 12/12 passed छापतात.

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

तोच code 100, 40 किंवा 80 गुणांच्या पेपरसाठी अचूक आहे, आणि 200 गुणांच्या पेपरसाठी चुकीचा आहे. फक्त पूर्ण संख्येतले scores वापरणारा test suite कायम pass होत राहिला असता. Bug 201 पैकी नेमक्या तीन inputs वर राहतो — 34.5, 44.5 आणि 74.5, म्हणजे grade रेषेच्या अगदी खालचे असे अर्धे, ज्यांचा सम शेजारी खाली आहे (59.5 हे 60 वर round होते, जो सम आहे, म्हणून ते योगायोगाने बरोबर येते). ते तीन शोधणे हाच धडा 03 चा विषय आहे.

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

फक्त सोपे, नेहमीचे inputs test करणे — "happy path"
"सगळे tests pass" म्हणजे "एकही bug नाही" असे समजणे
code चालवून त्याने जे छापले ते copy करून अपेक्षित उत्तर लिहिणे (मग test bug च तपासतो)
test न करता भाषेचे rounding, dates किंवा floats business नियमाशी जुळतील असा विश्वास ठेवणे
tests repo मध्ये न ठेवता laptop वर ठेवणे, जिथे प्रत्येक बदल ते चालवत नाही

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

हाच check pytest मध्ये, सर्वाधिक वापरला जाणारा Python test runner. खऱ्या project वर (pip install pytest), test_grades.py म्हणून save करा आणि pytest -q चालवा:

from exam.grades import grade

def test_half_mark_rounds_up_to_a_pass():
    assert grade(34.5) == "D"

pytest साधे assert पुन्हा लिहिते, म्हणून failure मध्ये दोन्ही बाजू दिसतात:

E       AssertionError: assert 'F' == 'D'

Python चे स्वतःचे documentation याच सापळ्याबद्दल इशारा देते: round(2.5) म्हणजे 2, कारण round() round-half-to-even ("banker's rounding") वापरते, आणि 2.675 सारखे floats अर्ध्याच्या थोडे खाली साठवले जातात. पैसे किंवा गुणांसाठी ठराविक नावाचा नियम हवा असेल, तर decimal वापरा:

from decimal import Decimal, ROUND_HALF_UP
Decimal("34.5").quantize(Decimal(1), rounding=ROUND_HALF_UP)   # Decimal('35')

🏭 Production मध्ये हे का महत्त्वाचे: business मधली व्यक्ती एका वाक्यात सांगू शकेल अशा प्रत्येक नियमासाठी ("35 म्हणजे pass", "अर्धा वर round होतो", "₹500 वरील orders मोफत ship होतात"), तेच वाक्य code मध्ये सांगणारा test असायला हवा — नेमक्या कडेसह.

⏭️ पुढे

एक प्रश्न म्हणजे एक test. तो चांगला कसा लिहायचा, आणि अनेक कसे चालवायचे? Arrange, act, assert, तुमच्या स्वतःच्या runner मध्ये आणि standard library च्या unittest मध्ये.

git checkout lesson-02-unit-tests

💸 Lesson 01 — Why test: the cost of a bug found late

📍 You are here: Lesson 01 of 12 · Next: lesson-02-unit-tests

📦 What's in this branch

The one idea this whole course is about: code is a pupil sitting an exam, and a test is an exam question with a known right answer. Dipika wrote the school's grading code. Katrina, the head examiner, wants to know if it is right before 1200 report cards are printed. Real files you will use all the way through:

exam/grades.py — the pupil: the school's grading module (grades, rounding, report cards, an attendance client, a small SQLite store)
exam/lab.py — the exam hall's tools as small deterministic models (a tiny runner, builders, stand-in examiners, a contract checker, a property tester, coverage, mutants, flaky tests)
exam/demo.py — every lesson as a small program (python3 exam/demo.py <section>; sections: why unit design fixtures doubles integration contract pyramid property mutation flaky ci)
exam/test_exam.py — the course's own 12 checks
demo-output.txt — what a healthy run prints

🎒 Before you start: you need Python 3 and nothing else — no pip install, no network. lab.py holds teaching models, not the real tools. Randomness is seeded, so every run prints the same story. The real tools are pytest, Hypothesis, Pact, Playwright, coverage.py and mutmut; every lesson shows them in blocks marked on a real project, which need pip install and are not part of Try it.

🧒 Explain like I'm 5

The school rule is simple: your percentage is rounded to a whole number, halves go up, and 35 is a pass.

Dipika writes the code. Katrina asks it five easy exam questions: 90? A. 65? B. 50? C. 40? D. 10? F. Five out of five. 🎉

Then the whole school sits a paper out of 200. A pupil with 69 marks gets 34.5%. The rule says 34.5 → 35 → pass. Dipika's code says F. ❌

Why? Python's round() does not round halves up. It rounds them to the nearest even number: round(34.5) is 34. The easy questions never asked about a half.

If Katrina finds this with one more question at Dipika's desk, the fix takes one line. If nobody finds it until the report cards are posted, it costs 15 reprints, 5 apology letters to pupils told they failed, and a meeting. Same bug. The only difference is when it was found.

🗺️ Diagram

flowchart LR
    code["✍️ Dipika writes grade_v1<br/>round() sends halves to EVEN"]
    easy["📝 5 easy questions<br/>90 65 50 40 10: 5/5 pass"]
    desk["🔍 found at the desk<br/>1 failing check, 0 pupils hurt"]
    late["📬 found after posting<br/>15 wrong cards, 5 told they failed"]
    code --> easy
    easy -->|"one question at 34.5"| desk
    easy -->|"no such question"| late

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

❓ What

Test — code that runs other code with a chosen input and checks the result against an expected answer. An exam question with the answer key attached.
Bug (defect) — the code does something different from what it should. Here: 34.5 gets F instead of D.
Specification — what "should" means. A test is only as right as its expected answer; the school rule "halves round up" is the spec here.
What a test proves — that the code gave the right answer for that input, on that day, in that setup. Nothing more.
What a test cannot prove — that there are no bugs. Edsger Dijkstra put it this way (1970): testing can show the presence of bugs, never their absence. grade_v1 passed 5 out of 5 and still had 3 wrong scores.
Cost of a late bug — a bug found later touches more people and more work: more code built on top, more data written, more people who saw the wrong answer. Books often quote ratios like "1× in design, 100× in production". Treat those as folklore: the original data is thin and disputed (Laurent Bossavit's The Leprechauns of Software Engineering traces them). The direction is real; the exact numbers are not a law.
Regression — something that used to work breaks after a change. A test that stays in the repo guards against it for ever after.

🤔 Why

Because the alternative is finding bugs through the people who use the software. Every test in this course is a question asked early, by a machine, in seconds, every time anyone changes the code. Tests also let you change code without fear: when Dipika fixes the rounding, 12 checks tell her in a second that nothing else broke. And a test is executable documentation: grade(34.5) == "D" says the rule more clearly than a comment.

🔧 How (in this repo)

grade_v1(score) in exam/grades.py uses Python's round(). grade(score) uses round_half_up(), which rounds with Decimal(str(score)) and ROUND_HALF_UP. why() in exam/demo.py asks grade_v1 five easy questions, then grades a seeded school of 1200 pupils on a paper out of 200 (so every score is a whole or a half) and counts how many cards differ from the fixed grade().

🧪 Try it

python3 exam/demo.py why
python3 - <<'EOF'
from exam.grades import grade, grade_v1
print("round() on halves:", [round(x) for x in (0.5, 1.5, 2.5, 34.5, 35.5, 74.5)])
for out_of in (100, 200, 40, 80):
    scores = [m * 100 / out_of for m in range(out_of + 1)]
    wrong = [s for s in scores if grade_v1(s) != grade(s)]
    print(f"paper out of {out_of:>3}: {len(scores):>3} possible scores · v1 wrong at {wrong}")
EOF
python3 exam/test_exam.py

✅ Verify — what you should see

why prints:

── 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

Your snippet prints:

round() on halves: [0, 2, 2, 34, 36, 74]
paper out of 100: 101 possible scores · v1 wrong at []
paper out of 200: 201 possible scores · v1 wrong at [34.5, 44.5, 74.5]
paper out of  40:  41 possible scores · v1 wrong at []
paper out of  80:  81 possible scores · v1 wrong at []

The checks end with 12/12 passed.

🏁 What you just proved

The same code is perfect for a paper out of 100, 40 or 80, and wrong for a paper out of 200. A test suite that only used whole-number scores would pass for ever. The bug lives at exactly three inputs out of 201 — 34.5, 44.5 and 74.5, the halves just below a grade line where the even neighbour is below it (59.5 rounds to 60, which is even, so it happens to be right). Finding those three is what lesson 03 is about.

⚠️ Common mistakes

testing only the easy, typical inputs — the "happy path"
reading "all tests pass" as "there are no bugs"
writing the expected answer by running the code and copying what it printed (the test then checks the bug)
trusting a language's rounding, dates or floats to match a business rule without a test
keeping tests on a laptop instead of in the repo, where every change runs them

🏭 In production

The same check in pytest, the most used Python test runner. On a real project (pip install pytest), save as test_grades.py and run pytest -q:

from exam.grades import grade

def test_half_mark_rounds_up_to_a_pass():
    assert grade(34.5) == "D"

pytest rewrites plain assert so a failure shows both sides:

E       AssertionError: assert 'F' == 'D'

Python's own documentation warns about this exact trap: round(2.5) is 2, because round() uses round-half-to-even ("banker's rounding"), and floats such as 2.675 are stored slightly below the half. When money or marks need a named rule, use decimal:

from decimal import Decimal, ROUND_HALF_UP
Decimal("34.5").quantize(Decimal(1), rounding=ROUND_HALF_UP)   # Decimal('35')

🏭 Why this matters in production: for every rule a business person can state in one sentence ("35 is a pass", "halves round up", "orders over ₹500 ship free"), there should be a test that says the same sentence in code — including the exact edge.

⏭️ Next

One question is a test. How do you write one well, and run many? Arrange, act, assert, in a runner of your own and in the standard library's unittest.

git checkout lesson-02-unit-tests

← Course homeall lessons Next →unit tests

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