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

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

🧑‍🏫 धडा 05 — Test doubles: बदली परीक्षक

📍 तुम्ही इथे आहात: 12 पैकी धडा 05 · मागे: lesson-04-fixtures · पुढे: lesson-06-integration

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

धडे 01–04, आणि test doubles: unit test ने खऱ्या स्वरूपात वापरू नयेत अशा भागांच्या जागी वापरलेले पर्याय. exam/grades.py मधला AttendanceClient attendance service ला (दुसरा server) विचारतो की विद्यार्थिनी किती दिवस आली. Tests त्या service च्या जागी stub, fake, spy किंवा mock वापरतात — आणि over-mocking मुळे test चुकीची गोष्ट कुठे तपासते ते शिकतात. exam/lab.py मधले StubTransport, FakeAttendance आणि SpyTransport, standard library मधले unittest.mock, आणि exam/demo.py मधले doubles().

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

खऱ्या attendance परीक्षक, सौ. राव, दुसऱ्या इमारतीत बसतात. प्रत्येक प्रश्नासाठी तिथे चालत जायला खूप वेळ लागतो, आणि काही दिवस त्या रजेवर असतात. म्हणून कतरिना बदली वापरते. 🧑‍🏫

Stub म्हणजे एकच कार्ड असलेली मदतनीस: "200 पैकी 172 दिवस". तुम्ही काहीही विचारा, ती तेच कार्ड दाखवते. "या उत्तराचे code काय करतो?" यासाठी उपयोगी.
Fake म्हणजे वहीत एक छोटी, चालणारी नोंदवही असलेली मदतनीस: तुम्ही विद्यार्थिनी जोडू शकता आणि शोधू शकता. खरी नोंदवही नाही, पण तशीच वागते.
Spy खऱ्या (किंवा fake) परीक्षकांच्या शेजारी उभी राहते आणि त्यांना विचारलेला प्रत्येक प्रश्न लिहून ठेवते.
Mock म्हणजे अशी मदतनीस जिला कोणता प्रश्न येणार हे आधीच सांगितलेले असते, आणि वेगळा प्रश्न आला तर ती तक्रार करते.

मग दीपिका उत्तर न बदलता प्रश्नाचे शब्द बदलते ("term 1 साठी, कृपया"). Fake तरीही उत्तर देते: test pass. ✅ Mock ला जुने शब्द अपेक्षित होते: test fail. ❌ Mock code ने कसे विचारले ते तपासत होते, त्याने काय निष्कर्ष काढला ते नाही.

आणि एके दिवशी stub चुकीच्या शीर्षकाचे कार्ड दाखवते. खऱ्या सौ. राव कधीच "present" लिहीत नाहीत — त्या "days_present" लिहितात. Test pass झाली; खरी शाळा मोडते. 😬

🗺️ आकृती

flowchart LR
    c["📇 AttendanceClient<br/>eligible if at least 75%"] --> t{"transport"}
    t -->|"production"| real["🏢 real attendance service"]
    t -->|"stub"| s["canned 172/200 → 86.0%"]
    t -->|"fake"| f["working dict<br/>42: 86.0% · 7: 70.0%"]
    t -->|"spy"| sp["records calls<br/>/attendance/42"]
    t -->|"mock"| m["expects exact call<br/>fails on ?term=1"]

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

❓ काय

ही नावे Gerard Meszaros यांच्या xUnit Test Patterns (2007) मधून आली आहेत; Martin Fowler यांचा निबंध Mocks Aren't Stubs हा फरक छान समजावतो.

Test double — test मध्ये खऱ्या object च्या जागी उभा राहणारा कोणताही object (चित्रपटातल्या stunt double सारखा).
Dummy — फक्त parameter भरण्यासाठी दिलेला; कधीच वापरला जात नाही.
Stub — ठरलेली उत्तरे परत देतो. Test होणाऱ्या code ला एखाद्या स्थितीत आणण्यासाठी वापरतात: "service म्हणते 404", "service म्हणते 503".
Fake — चालणारी, सोपी अंमलबजावणी: in-memory database, dict वर आधारित service. खरे वर्तन, पण production साठी तयार नाही.
Spy — त्याला कसे बोलवले गेले ते नोंदवतो, म्हणजे test नंतर तपासू शकते.
Mock — calls बद्दलच्या अपेक्षा आधीच program केलेल्या, आणि तो त्या पडताळतो. Python मध्ये, unittest.mock.Mock हा लवचिक object आहे जो stub सारखा वागू शकतो (return_value, side_effect) आणि spy सारखे calls नोंदवतो (assert_called_once_with).
State verification विरुद्ध behaviour verification — निकाल तपासा (विद्यार्थिनी eligible आहे), किंवा calls तपासा (client ने /attendance/42 बोलवले). State verification refactoring मध्ये जास्त चांगले टिकते.
Over-mocking — इतके doubles, इतक्या नेमकेपणाने तपासलेले, की test code ओळ-न-ओळ पुन्हा सांगते. Code refactor केला की ती मोडते, आणि खरा सहकारी बदलला तरी ती pass होते.
Dependency injection — client आपला transport parameter म्हणून घेतो, म्हणजे test double देऊ शकते. आतच स्वतःचे HTTP connection तयार करणारा code test करायला कठीण असतो.

🤔 का

कारण unit test वेगवान आणि खात्रीशीर असायला हवी, आणि खरी service दोन्हीपैकी काहीच नाही: ती network वर आहे (distributed-systems शाळेचा धडा 01), ती बंद असू शकते, आणि तिच्याकडे तुमच्या नियंत्रणात नसलेला data असतो. Doubles मुळे "503 वर काय होते?" हे तुम्ही एका millisecond मध्ये विचारू शकता. पण प्रत्येक double हा खऱ्या गोष्टीबद्दलचा एक दावा आहे. कोणीच न तपासलेला दावा चुकीचा असू शकतो — धडा 07 तो तपासतो.

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

exam/grades.py मधला AttendanceClient(transport) transport("/attendance/<id>") बोलवतो आणि (status, body) अपेक्षित धरतो. 404 वर तो StudentNotFound देतो, 5xx वर AttendanceUnavailable, आणि अन्यथा days_present × 100 ÷ days_total मोजतो, एका दशांशापर्यंत round करून. exam/lab.py मध्ये, StubTransport(status, body) नेहमी तीच जोडी परत देतो, FakeAttendance विद्यार्थिनींची dict ठेवतो आणि अनोळखींसाठी 404 उत्तर देतो, आणि SpyTransport(inner) calls पुढे पाठवतो आणि प्रत्येक path calls मध्ये जोडतो.

🧪 करून पाहा

python3 exam/demo.py doubles
python3 - <<'EOF'
from unittest import mock
from exam.grades import AttendanceClient, StudentNotFound, AttendanceUnavailable
from exam.lab import StubTransport, FakeAttendance, SpyTransport
for status in (200, 404, 500, 503):
    c = AttendanceClient(StubTransport(status, {"days_present": 150, "days_total": 200}))
    try: print(f"stub says {status} → eligible {c.eligible('9')}")
    except (StudentNotFound, AttendanceUnavailable) as e: print(f"stub says {status} → {type(e).__name__}")
fake = FakeAttendance().add("1", 149, 200).add("2", 150, 200)
spy = SpyTransport(fake); c = AttendanceClient(spy)
print("149/200:", c.eligible("1"), "· 150/200:", c.eligible("2"), "· calls:", spy.calls)
m = mock.Mock(side_effect=[(503, {}), (200, {"days_present": 180, "days_total": 200})])
c = AttendanceClient(m)
for _ in range(2):
    try: print("mock →", c.attendance_percent("5"))
    except AttendanceUnavailable: print("mock → AttendanceUnavailable")
print("mock was called", m.call_count, "times with", m.call_args_list[0])
EOF

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

doubles छापते:

   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
   fake-based test: eligible True → passes · mock-based test → FAILS (the mock checked HOW, not WHAT)

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

stub says 200 → eligible True
stub says 404 → StudentNotFound
stub says 500 → AttendanceUnavailable
stub says 503 → AttendanceUnavailable
149/200: False · 150/200: True · calls: ['/attendance/1', '/attendance/2']
mock → AttendanceUnavailable
mock → 90.0
mock was called 2 times with call('/attendance/5')

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

Stub मुळे तुम्ही चार ओळींत प्रत्येक status code पाहू शकलात — खरी service हे मागणीवर क्वचितच करेल. Fake ला अशी कड सापडली जी stub ला सापडली नसती: 200 पैकी 149 दिवस म्हणजे 74.5%, जे eligible नाही. side_effect यादीमुळे mock एकदा fail झाले आणि मग उत्तर दिले — retry test चा हाच आकार. आणि demo over-mocking ची किंमत दाखवतो: URL मधल्या निरुपद्रवी बदलाने mock-based test मोडली, तर चुकीच्या field नावांचा stub आनंदाने pass झाला आणि production मध्ये KeyError 'days_present' ने crash झाला असता.

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

सगळ्याचेच mocking करणे, तुमच्या स्वतःच्या साध्या objects सह (खरा object च वापरा)
प्रत्येक call आणि argument वर assert करणे, म्हणजे कोणताही refactor test मोडतो
खरी service कधीच देत नाही अशी उत्तरे देणारे stubs (चुकीची field नावे, चुकीचे types)
library ला स्वतःच्या छोट्या interface मध्ये गुंडाळण्याऐवजी तिच्या आतल्या भागांचे mocking करणे
चुकीच्या नावावर mock.patch — code जिथे ते शोधतो तिथे patch करा, जिथे ते define केले आहे तिथे नाही

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

खऱ्या project वर — unittest.mock.patch test च्या कालावधीपुरते एक नाव बदलते, आणि autospec=True मुळे double खरे function स्वीकारू शकणार नाही असे calls नाकारतो:

from unittest import mock
import exam.grades

def test_report_uses_attendance():
    with mock.patch.object(exam.grades.AttendanceClient, "attendance_percent",
                           autospec=True, return_value=80.0):
        assert exam.grades.AttendanceClient(None).eligible("42") is True

autospec signature तपासते, उत्तरे नाही — खऱ्या service ने field चे नाव बदलले हे ते सांगू शकत नाही. HTTP साठी, record-and-replay आणि stub-server साधने मदत करतात: responses आणि respx (Python), WireMock (Java, स्वतंत्र server म्हणूनही चालते), MSW (JavaScript). तुमच्या स्वतःच्या dependencies साठी, खऱ्या implementation शेजारी तुम्ही सांभाळलेला fake वापरा आणि दोन्ही एकाच checks वर test करा.

🏭 Production मध्ये हे का महत्त्वाचे: तुमच्या suite मधल्या प्रत्येक double बद्दल विचारा "याला प्रामाणिक कोण ठेवते?" उत्तर "कोणीच नाही" असेल, तर तो दुसऱ्या team च्या service बद्दलचा अंदाज आहे. Contract tests (धडा 07) किंवा integration tests चा छोटा संच (धडा 06) त्या अंदाजाला तपासणीत बदलतात.

⏭️ पुढे

धडा 04 मधला fake store हा Python dict होता. खरा store SQL आहे. Integration tests खरा SQLite database वापरतात — आणि fake ला न सापडणारा bug शोधतात.

git checkout lesson-06-integration

🧑‍🏫 Lesson 05 — Test doubles: stand-in examiners

📍 You are here: Lesson 05 of 12 · Previous: lesson-04-fixtures · Next: lesson-06-integration

📦 What's in this branch

Lessons 01–04, plus test doubles: stand-ins for the parts a unit test should not use for real. AttendanceClient in exam/grades.py asks the attendance service (another server) how many days a pupil came. Tests replace that service with a stub, a fake, a spy or a mock — and learn where over-mocking makes a test check the wrong thing. StubTransport, FakeAttendance and SpyTransport in exam/lab.py, unittest.mock from the standard library, and doubles() in exam/demo.py.

🧒 Explain like I'm 5

The real attendance examiner, Mrs Rao, sits in another building. Walking there for every question takes ages, and some days she is on leave. So Katrina uses stand-ins. 🧑‍🏫

A stub is a helper with one card: "172 days out of 200". Whatever you ask, she shows the card. Good for "what does the code do with this answer?"
A fake is a helper with a small, working register in a notebook: you can add pupils and look them up. Not the real register, but it behaves like one.
A spy stands next to the real (or fake) examiner and writes down every question she was asked.
A mock is a helper who was told in advance which question to expect, and complains if a different one comes.

Then Dipika changes how the question is worded ("for term 1, please") without changing the answer. The fake still answers: test passes. ✅ The mock expected the old wording: test fails. ❌ The mock was checking how the code asked, not what it concluded.

And one day the stub shows a card with the wrong heading. The real Mrs Rao never writes "present" — she writes "days_present". The test passed; the real school breaks. 😬

🗺️ Diagram

flowchart LR
    c["📇 AttendanceClient<br/>eligible if at least 75%"] --> t{"transport"}
    t -->|"production"| real["🏢 real attendance service"]
    t -->|"stub"| s["canned 172/200 → 86.0%"]
    t -->|"fake"| f["working dict<br/>42: 86.0% · 7: 70.0%"]
    t -->|"spy"| sp["records calls<br/>/attendance/42"]
    t -->|"mock"| m["expects exact call<br/>fails on ?term=1"]

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

❓ What

The names come from Gerard Meszaros, xUnit Test Patterns (2007); Martin Fowler's essay Mocks Aren't Stubs explains the difference well.

Test double — any object that stands in for a real one in a test (like a stunt double in a film).
Dummy — passed only to fill a parameter; never used.
Stub — returns canned answers. Used to put the code under test into a state: "the service says 404", "the service says 503".
Fake — a working, simpler implementation: an in-memory database, a dict-backed service. Real behaviour, not production-ready.
Spy — records how it was called, so the test can check afterwards.
Mock — pre-programmed with expectations about calls, and verifies them. In Python, unittest.mock.Mock is a flexible object that can act as a stub (return_value, side_effect) and records calls like a spy (assert_called_once_with).
State verification vs behaviour verification — check the result (the pupil is eligible), or check the calls (the client called /attendance/42). State verification survives refactoring better.
Over-mocking — so many doubles, checked so exactly, that the test repeats the code line by line. It breaks when the code is refactored, and it passes when the real collaborator has changed.
Dependency injection — the client takes its transport as a parameter, so a test can pass a double. Code that creates its own HTTP connection inside is hard to test.

🤔 Why

Because a unit test must be fast and certain, and the real service is neither: it is on the network (lesson 01 of the distributed-systems school), it can be down, and it holds data you do not control. Doubles let you ask "what happens on a 503?" in a millisecond. But every double is a claim about the real thing. A claim nobody checks can be wrong — lesson 07 checks it.

🔧 How (in this repo)

AttendanceClient(transport) in exam/grades.py calls transport("/attendance/<id>") and expects (status, body). It raises StudentNotFound on 404, AttendanceUnavailable on 5xx, and otherwise computes days_present × 100 ÷ days_total, rounded to one decimal. In exam/lab.py, StubTransport(status, body) always returns the same pair, FakeAttendance keeps a dict of pupils and answers 404 for unknown ones, and SpyTransport(inner) passes calls through and appends each path to calls.

🧪 Try it

python3 exam/demo.py doubles
python3 - <<'EOF'
from unittest import mock
from exam.grades import AttendanceClient, StudentNotFound, AttendanceUnavailable
from exam.lab import StubTransport, FakeAttendance, SpyTransport
for status in (200, 404, 500, 503):
    c = AttendanceClient(StubTransport(status, {"days_present": 150, "days_total": 200}))
    try: print(f"stub says {status} → eligible {c.eligible('9')}")
    except (StudentNotFound, AttendanceUnavailable) as e: print(f"stub says {status} → {type(e).__name__}")
fake = FakeAttendance().add("1", 149, 200).add("2", 150, 200)
spy = SpyTransport(fake); c = AttendanceClient(spy)
print("149/200:", c.eligible("1"), "· 150/200:", c.eligible("2"), "· calls:", spy.calls)
m = mock.Mock(side_effect=[(503, {}), (200, {"days_present": 180, "days_total": 200})])
c = AttendanceClient(m)
for _ in range(2):
    try: print("mock →", c.attendance_percent("5"))
    except AttendanceUnavailable: print("mock → AttendanceUnavailable")
print("mock was called", m.call_count, "times with", m.call_args_list[0])
EOF

✅ Verify — what you should see

doubles prints:

   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
   fake-based test: eligible True → passes · mock-based test → FAILS (the mock checked HOW, not WHAT)

Your snippet prints:

stub says 200 → eligible True
stub says 404 → StudentNotFound
stub says 500 → AttendanceUnavailable
stub says 503 → AttendanceUnavailable
149/200: False · 150/200: True · calls: ['/attendance/1', '/attendance/2']
mock → AttendanceUnavailable
mock → 90.0
mock was called 2 times with call('/attendance/5')

🏁 What you just proved

A stub let you visit every status code in four lines — something the real service would rarely do on demand. The fake found an edge a stub would not: 149 of 200 days is 74.5%, which is not eligible. The side_effect list made the mock fail once and then answer, the shape of a retry test. And the demo shows the price of over-mocking: a harmless change to the URL broke the mock-based test, while a stub with the wrong field names passed happily and would crash in production with KeyError 'days_present'.

⚠️ Common mistakes

mocking everything, including simple objects you own (just use the real one)
asserting on every call and argument, so any refactor breaks the test
stubs whose answers the real service never gives (wrong field names, wrong types)
mocking a library's internals instead of wrapping it in your own small interface
mock.patch on the wrong name — patch where the code looks it up, not where it is defined

🏭 In production

On a real project — unittest.mock.patch swaps a name for the length of a test, and autospec=True makes the double refuse calls the real function could not accept:

from unittest import mock
import exam.grades

def test_report_uses_attendance():
    with mock.patch.object(exam.grades.AttendanceClient, "attendance_percent",
                           autospec=True, return_value=80.0):
        assert exam.grades.AttendanceClient(None).eligible("42") is True

autospec checks the signature, not the answers — it cannot tell you the real service renamed a field. For HTTP, record-and-replay and stub-server tools help: responses and respx (Python), WireMock (Java, also runs as a standalone server), MSW (JavaScript). For your own dependencies, prefer a fake you maintain next to the real implementation and test both against the same checks.

🏭 Why this matters in production: for each double in your suite, ask "what keeps this honest?" If the answer is "nothing", it is a guess about another team's service. Contract tests (lesson 07) or a small set of integration tests (lesson 06) turn the guess into a check.

⏭️ Next

The fake store in lesson 04 was a Python dict. The real store is SQL. Integration tests use a real SQLite database — and find a bug the fake cannot.

git checkout lesson-06-integration

← Previousfixtures Next →integration

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