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

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

🗂️ धडा 04 — Fixtures आणि test data: तयार उत्तरपत्रिका

📍 तुम्ही इथे आहात: 12 पैकी धडा 04 · मागे: lesson-03-test-design · पुढे: lesson-05-test-doubles

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

धडे 01–03, आणि fixtures: test ला आपला प्रश्न विचारण्यापूर्वी लागणारा data आणि setup. Builders एका ओळीत वैध test data बनवतात; setup आणि teardown प्रत्येक test ला नवी sheet देतात आणि नंतर साफसफाई करतात, test crash झाली तरीही; आणि स्वतंत्र tests कोणत्याही क्रमाने pass होतात. exam/lab.py मधले StudentBuilder, a_student() आणि Runner.run(setup=…, teardown=…); exam/demo.py मधले fixtures().

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

परीक्षेपूर्वी office प्रत्येक विद्यार्थिनीसाठी एक उत्तरपत्रिका तयार करते: नाव छापलेले, चौकटी तयार. 🗂️ तोच fixture.

कतरिनाकडे एक हुशार युक्ती आहे: एक तयार विद्यार्थिनी. a_student() म्हणजे स्वतः कतरिना, चांगले गुण आणि 90% attendance सह — pass होणारी सामान्य विद्यार्थिनी. "कमी attendance" test करण्यासाठी ती फक्त तेवढेच बदलते: a_student().with_attendance(60). बाकी सगळे सामान्य राहते, म्हणून test स्पष्टपणे attendance बद्दलच आहे.

मग एक गोंधळ. दोन प्रश्न एकच sheet वापरतात. पहिला प्रश्न त्यावर ऐश्वर्याचे नाव लिहितो. दुसऱ्या प्रश्नाला कोरी sheet अपेक्षित असते — आणि त्याला नाव सापडते. ❌ क्रम उलटा करा आणि दोन्ही pass. ✅ आधी कोण गेले यावर pass किंवा fail होणारी test ही वाईट test आहे.

दुरुस्ती: प्रत्येक प्रश्नासाठी नवी sheet (setup), आणि प्रत्येक प्रश्नानंतर sheet परत घेतली जाते (teardown), विद्यार्थिनीने शाई सांडली तरीही. 🧹

🗺️ आकृती

flowchart LR
    b["🏗️ a_student()<br/>Katrina · avg 75.0 · A · promoted"] --> b1[".with_attendance(60)<br/>promoted False"]
    b1 --> b2[".with_medical_note()<br/>promoted True"]
    subgraph shared["😬 one shared sheet"]
      s1["enrol then empty: 1 passed, 1 failed"]
      s2["empty then enrol: 2 passed"]
    end
    subgraph fresh["✅ fresh sheet per test"]
      f1["setup → test → teardown<br/>2 passed in both orders"]
    end

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

❓ काय

Fixture — test ने act करण्यापूर्वी जागेवर असायला हवे ते सगळे: objects, files, rows असलेला database. "Test fixture" हे xUnit मधले नाव आहे; pytest सुद्धा आपल्या setup functions ना fixtures म्हणते.
Setup / teardown — प्रत्येक test च्या आधी आणि नंतर चालणारा code. Test fail झाली तरी teardown चाललाच पाहिजे, नाहीतर पुढच्या test ला गोंधळ वारसा म्हणून मिळतो. unittest मध्ये: setUp आणि tearDown; pytest मध्ये: yield असलेला fixture.
Test data builder — वैध default object परत देणारा मदतनीस, एक field बदलण्याच्या methods सह: a_student().with_marks(maths=10). Nat Pryce आणि Steve Freeman यांच्या Growing Object-Oriented Software, Guided by Tests मधून. Test फक्त तिच्यासाठी महत्त्वाचे तेच सांगते.
Object mother — नावे दिलेल्या तयार objects चा संच (failing_pupil(), top_pupil()). सोपे, पण प्रत्येक प्रकारासाठी एक नवे function वाढत जाते; builders जास्त चांगले वाढतात.
Test independence (isolation) — प्रत्येक test एकटी, सगळ्यांसोबत, आणि कोणत्याही क्रमाने pass होते. Shared mutable state (एक global list, सगळ्या tests साठी एकच database, disk वरची एक file) हे मोडते.
Scope — fixture किती काळ जगतो: प्रत्येक test साठी (सर्वात सुरक्षित), प्रत्येक class, प्रत्येक module, प्रत्येक session (सर्वात वेगवान, ज्या महाग गोष्टी tests फक्त वाचतात त्यांच्यासाठी).

🤔 का

कारण बहुतेक test suites मधला बहुतांश code म्हणजे test data असतो. प्रत्येक test 12 fields सह विद्यार्थिनी हाताने बनवत असेल, तर एक नवे required field 300 tests मोडते, आणि test कोणत्या field बद्दल आहे ते कोणालाच दिसत नाही. आणि shared state मुळे क्रमावर अवलंबून failures येतात — त्या तुमच्या laptop वर pass होतात आणि CI मध्ये fail, जे tests वेगळ्या क्रमाने किंवा parallel मध्ये चालवते (धडा 11).

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

exam/lab.py मधला StudentBuilder कतरिनापासून सुरू होतो (maths 80, science 70, english 75, attendance 90). named(), with_marks(**m), with_attendance() आणि with_medical_note() प्रत्येकी एक गोष्ट बदलतात आणि builder परत देतात; card() खरे report_card() बोलवते. Runner.run(setup=…, teardown=…) प्रत्येक test आधी setup() बोलवतो, त्याचा निकाल test ला देतो, आणि finally: block मध्ये teardown(fixture) बोलवतो.

🧪 करून पाहा

python3 exam/demo.py fixtures
python3 - <<'EOF'
from exam.lab import a_student, Runner, expect, summary
print(a_student().card())
print(a_student().with_marks(maths=10).card()["grade"], a_student().with_marks(maths=10, science=10).card()["grade"])
log = []
def setup(): log.append("setup"); return {"store": [], "open": True}
def teardown(fx): fx["open"] = False; log.append("teardown")
def saves_one(fx): fx["store"].append("Katrina"); expect(len(fx["store"]), 1)
def crashes(fx): fx["store"].append("Dipika"); raise RuntimeError("printer jammed")
def starts_empty(fx): expect(fx["store"], [])
r = Runner(); r.tests = [saves_one, crashes, starts_empty]
for n, o in r.run(setup=setup, teardown=teardown): print(f"{n:<13} {o}")
print(log)
EOF

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

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

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

{'name': 'Katrina', 'average': 75.0, 'grade': 'A', 'attendance': 90, 'promoted': True}
C F
saves_one     pass
crashes       ERROR — RuntimeError: printer jammed
starts_empty  pass
['setup', 'teardown', 'setup', 'teardown', 'setup', 'teardown']

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

Builder ने प्रत्येक ओळीत एकच बदल केला आणि बाकी काहीच हलले नाही: maths मधला एकच 10 कतरिनाला C वर आणतो, दोन तिला F वर आणतात. Shared sheet सह, निकाल क्रमावर अवलंबून होता (1 failed विरुद्ध 0 failed). प्रत्येक test ला नवी sheet असताना, crashes ने दीपिकाचे नाव लिहून उडी मारल्यानंतर लगेचही starts_empty pass झाली — आणि log मध्ये तीन setups आणि तीन teardowns दिसतात, म्हणजे crash झालेल्या test नंतरही साफसफाई झाली.

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

एकच मोठा shared fixture ज्यात प्रत्येक test थोडा बदल करते
प्रत्येक field लिहून test data बनवणे, म्हणजे test कशाबद्दल आहे ते कोणालाच दिसत नाही
test body च्या शेवटी cleanup — test fail झाली की तो कधीच चालत नाही
session-scoped database ज्यात tests लिहितात
seed शिवाय random किंवा वेळेवर आधारित test data (धडा 11)

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

खऱ्या project वर — yield नंतर teardown असलेला pytest fixture; test fail झाली तरी pytest yield नंतरचा भाग चालवते:

import pytest
from exam.grades import GradeStore

@pytest.fixture
def store():
    s = GradeStore(":memory:")       # setup: a fresh database for THIS test
    yield s
    s.db.close()                     # teardown

def test_average(store):
    store.save("Katrina", "maths", 68)
    assert store.class_average("maths") == 68

तुम्हाला भेटतील असे pytest चे built-in fixtures: tmp_path (प्रत्येक test साठी नवी temporary directory), monkeypatch (environment variable किंवा attribute set करा, test नंतर परत पूर्ववत), capsys (छापलेला output पकडा). हळू, read-only fixture ला जास्त मोठा scope देता येतो:

@pytest.fixture(scope="session")
def reference_marks():
    return load_big_csv("marks-2025.csv")    # loaded once, never modified

इतर ecosystems: वास्तववादी किमती असलेल्या builders साठी factory_boy (Python) आणि Faker; JUnit 5 @BeforeEach / @AfterEach; Jest beforeEach / afterEach.

🏭 Production मध्ये हे का महत्त्वाचे: अधूनमधून तुमची suite random क्रमाने चालवा (pytest-randomly plugin हे प्रत्येक run ला करते). फक्त काही क्रमांमध्येच fail होणारी कोणतीही test state गळवत आहे — CI रात्री 2 वाजता तुमच्यासाठी ती शोधण्यापूर्वी तुम्हीच शोधा.

⏭️ पुढे

काही गोष्टी test ला खऱ्या स्वरूपात सहज वापरता येत नाहीत: attendance service दुसऱ्या server वर आहे. बदली परीक्षक — stubs, fakes, spies आणि mocks — तिची जागा घेतात.

git checkout lesson-05-test-doubles

🗂️ Lesson 04 — Fixtures & test data: prepared answer sheets

📍 You are here: Lesson 04 of 12 · Previous: lesson-03-test-design · Next: lesson-05-test-doubles

📦 What's in this branch

Lessons 01–03, plus the fixtures: the data and setup a test needs before it can ask its question. Builders make valid test data with one line; setup and teardown give every test a fresh sheet and clean up after it, even when the test crashes; and independent tests pass in any order. StudentBuilder, a_student() and Runner.run(setup=…, teardown=…) in exam/lab.py; fixtures() in exam/demo.py.

🧒 Explain like I'm 5

Before an exam, the office prepares an answer sheet for every pupil: name printed, boxes ready. 🗂️ That is a fixture.

Katrina has a clever trick: a ready-made pupil. a_student() is Katrina herself, with good marks and 90% attendance — a normal pupil who passes. To test "low attendance", she changes only that: a_student().with_attendance(60). Everything else stays normal, so the test is clearly about attendance.

Then a mess. Two questions share one sheet. The first question writes Aishwarya's name on it. The second question expects a blank sheet — and finds a name. ❌ Swap the order and both pass. ✅ A test that passes or fails depending on who went first is a bad test.

The fix: a fresh sheet for every question (setup), and the sheet is collected after each one (teardown), even if the pupil knocks the ink over. 🧹

🗺️ Diagram

flowchart LR
    b["🏗️ a_student()<br/>Katrina · avg 75.0 · A · promoted"] --> b1[".with_attendance(60)<br/>promoted False"]
    b1 --> b2[".with_medical_note()<br/>promoted True"]
    subgraph shared["😬 one shared sheet"]
      s1["enrol then empty: 1 passed, 1 failed"]
      s2["empty then enrol: 2 passed"]
    end
    subgraph fresh["✅ fresh sheet per test"]
      f1["setup → test → teardown<br/>2 passed in both orders"]
    end

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

❓ What

Fixture — everything a test needs in place before it acts: objects, files, a database with rows in it. "Test fixture" is the xUnit name; pytest calls its setup functions fixtures too.
Setup / teardown — code run before and after each test. Teardown must run even when the test fails, or the next test inherits the mess. In unittest: setUp and tearDown; in pytest: a fixture with yield.
Test data builder — a helper that returns a valid default object, with methods to change one field: a_student().with_marks(maths=10). From Nat Pryce's and Steve Freeman's Growing Object-Oriented Software, Guided by Tests. The test states only what matters to it.
Object mother — a set of named ready-made objects (failing_pupil(), top_pupil()). Simple, but it grows a new function for every variation; builders scale better.
Test independence (isolation) — every test passes alone, together, and in any order. Shared mutable state (a global list, one database for all tests, a file on disk) breaks it.
Scope — how long a fixture lives: per test (safest), per class, per module, per session (fastest, for expensive things that tests only read).

🤔 Why

Because test data is most of the code in most test suites. When every test builds a pupil by hand with 12 fields, one new required field breaks 300 tests, and nobody can see which field a test is about. And shared state makes failures that depend on order — they pass on your laptop and fail in CI, which runs tests in a different order or in parallel (lesson 11).

🔧 How (in this repo)

StudentBuilder in exam/lab.py starts from Katrina (maths 80, science 70, english 75, attendance 90). named(), with_marks(**m), with_attendance() and with_medical_note() each change one thing and return the builder; card() calls the real report_card(). Runner.run(setup=…, teardown=…) calls setup() before each test, passes the result to it, and calls teardown(fixture) in a finally: block.

🧪 Try it

python3 exam/demo.py fixtures
python3 - <<'EOF'
from exam.lab import a_student, Runner, expect, summary
print(a_student().card())
print(a_student().with_marks(maths=10).card()["grade"], a_student().with_marks(maths=10, science=10).card()["grade"])
log = []
def setup(): log.append("setup"); return {"store": [], "open": True}
def teardown(fx): fx["open"] = False; log.append("teardown")
def saves_one(fx): fx["store"].append("Katrina"); expect(len(fx["store"]), 1)
def crashes(fx): fx["store"].append("Dipika"); raise RuntimeError("printer jammed")
def starts_empty(fx): expect(fx["store"], [])
r = Runner(); r.tests = [saves_one, crashes, starts_empty]
for n, o in r.run(setup=setup, teardown=teardown): print(f"{n:<13} {o}")
print(log)
EOF

✅ Verify — what you should see

fixtures prints:

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

Your snippet prints:

{'name': 'Katrina', 'average': 75.0, 'grade': 'A', 'attendance': 90, 'promoted': True}
C F
saves_one     pass
crashes       ERROR — RuntimeError: printer jammed
starts_empty  pass
['setup', 'teardown', 'setup', 'teardown', 'setup', 'teardown']

🏁 What you just proved

The builder made one change per line and nothing else moved: a single 10 in maths drops Katrina to C, two drop her to F. With a shared sheet, the result depended on the order (1 failed vs 0 failed). With a fresh sheet per test, starts_empty passed even right after crashes wrote Dipika's name and blew up — and the log shows three setups and three teardowns, so the crashed test was cleaned up too.

⚠️ Common mistakes

one big shared fixture that every test changes a little
building test data with every field spelled out, so nobody can see what the test is about
cleanup at the end of the test body — it never runs when the test fails
a session-scoped database that tests write to
random or time-based test data without a seed (lesson 11)

🏭 In production

On a real project — a pytest fixture with teardown after yield; pytest runs the part after yield even when the test fails:

import pytest
from exam.grades import GradeStore

@pytest.fixture
def store():
    s = GradeStore(":memory:")       # setup: a fresh database for THIS test
    yield s
    s.db.close()                     # teardown

def test_average(store):
    store.save("Katrina", "maths", 68)
    assert store.class_average("maths") == 68

Built-in pytest fixtures you will meet: tmp_path (a fresh temporary directory per test), monkeypatch (set an environment variable or attribute, undone after the test), capsys (capture printed output). A slow, read-only fixture can have a wider scope:

@pytest.fixture(scope="session")
def reference_marks():
    return load_big_csv("marks-2025.csv")    # loaded once, never modified

Other ecosystems: factory_boy (Python) and Faker for builders with realistic values; JUnit 5 @BeforeEach / @AfterEach; Jest beforeEach / afterEach.

🏭 Why this matters in production: run your suite in a random order now and then (the pytest-randomly plugin does it on every run). Any test that fails only in some orders is leaking state — find it before CI does it for you at 2 a.m.

⏭️ Next

Some things a test cannot easily use for real: the attendance service is on another server. Stand-in examiners — stubs, fakes, spies and mocks — take its place.

git checkout lesson-05-test-doubles

← Previoustest design Next →test doubles

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