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

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

🚦 धडा 12 — CI मधील tests आणि TDD: red, green, refactor — आणि संपूर्ण चित्र

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 · मागील: lesson-11-flaky-tests

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

धडे 01–11, आणि त्याशिवाय tests कधी चालतात. Test-driven development (TDD) उत्तराच्या आधी परीक्षेचा प्रश्न लिहिते: red, green, refactor. Continuous integration (CI) प्रत्येक बदलावर suite चालवते, वेगवान तपासण्या आधी, आणि test selection बदलाचा परिणाम होऊ शकणाऱ्या tests च फक्त चालवते. grace_v0, grace_v1, grace_v2, GRACE_TESTS, SUITES आणि select_tests() exam/lab.py मध्ये; ci() exam/demo.py मध्ये. आणि संपूर्ण कोर्स एका पानावर.

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

शाळेचा एक नवा नियम येतो: "जी विद्यार्थिनी 35 पासून 2 गुण किंवा त्याहून कमी मागे आहे, आणि जिच्याकडे medical note आहे, तिला 35 पर्यंत वर घ्यावे."

कतरिना एक वेगळीच गोष्ट करते. ती आधी परीक्षेचे प्रश्न 📝 लिहिते — पाच: note सह 33 → 35; note सह 34.9 → 35; note शिवाय 33 → 33; note सह 32.9 → 32.9; note सह 35 → 35. ती ते चालवते. पाचही fail होतात — अजून code च नाही. 🔴 हे red. यावरून सिद्ध होते की प्रश्न fail होऊ शकतात.

दीपिका pass होणारा सर्वात साधा code लिहिते. पुन्हा चालवा: 5 पैकी 5. 🟢 Green.

मग दीपिका तो नीटनेटका करते — "2 गुण" ला एक नाव देते, शाळेचा pass-mark constant वापरते. पुन्हा चालवा: तरीही 5 पैकी 5. 🔵 Refactor झाले, सुरक्षितपणे.

आणि जेव्हा जेव्हा कोणी काहीही बदलते, तेव्हा ऐश्वर्याचा CI हॉल 🚦 प्रश्न आपोआप चालवतो: आधी झटपट प्रश्न, आणि फक्त त्याच प्रश्नपत्रिका ज्यांच्यावर बदलाचा परिणाम होऊ शकतो. Attendance code मधला बदल सगळे 105 नव्हे, तर 28 प्रश्न चालवतो. पण कोणतीही गोष्ट main branch मध्ये जाण्याआधी, प्रत्येक प्रश्नपत्रिका सोडवली जाते.

🗺️ आकृती

flowchart LR
    red["🔴 RED<br/>5 tests first, 0/5 pass"] --> green["🟢 GREEN<br/>simplest code, 5/5"]
    green --> ref["🔵 REFACTOR<br/>name the rule, 5/5"]
    ref -->|"push"| ci["🚦 CI: lint → unit → integration → contract → e2e"]
    ci --> sel["change to attendance<br/>3 of 6 suites, 28 of 105 tests"]
    ci --> main["merge to main<br/>all 105 tests"]

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

❓ काय

TDD (test-driven development) — Kent Beck, Test-Driven Development: By Example (2002). एक छोटे चक्र: red (पुढच्या छोट्या वागणुकीसाठी fail होणारी test लिहा), green (pass होणारा सर्वात साधा code), refactor (tests ना सुरक्षा-जाळे मानून साफसफाई). TDD चा defects आणि वेगावर होणाऱ्या परिणामाच्या अभ्यासांचे निकाल संमिश्र आहेत; त्याचा सर्वात स्पष्ट फायदा म्हणजे test करता येणारी design, आणि पहिल्या दिवसापासून अस्तित्वात असलेला suite.
आधी red का — जी test तुम्ही कधीच fail होताना पाहिली नाही, ती कदाचित fail होऊच शकत नसेल (धडा 02 मधली "assert नाही" ही चूक).
Continuous integration (CI) — प्रत्येक बदल वारंवार merge होतो आणि एका server वर आपोआप build आणि test होतो (GitHub Actions, GitLab CI, Jenkins, आणि इतर).
Fail fast — pipeline वेगानुसार मांडा: lint आणि type checks (seconds), unit tests, integration, contract, मग थोडे e2e tests. पहिल्या red वर थांबा.
Test selection (test impact analysis) — dependency map (Bazel चा build graph), coverage data (pytest-testmon), किंवा मागच्या failures वर train केलेले model (Meta चे predictive test selection) वापरून, बदललेल्या code वर अवलंबून असलेल्या tests च फक्त चालवा. पूर्ण suite कुठे ना कुठे नेहमी चालवा — merge वेळी किंवा रात्री — कारण map चुकीचा असू शकतो.
Parallelism आणि sharding — suite CPU cores किंवा machines मध्ये वाटा (pytest-xdist, CI matrix jobs). फक्त स्वतंत्र tests असतील तरच सुरक्षित (धडा 04).
Required checks — ठरवलेले CI jobs green होईपर्यंत repository merge नाकारते.

🤔 का

कारण test suite चालला तरच उपयोगी असतो — प्रत्येक बदलावर, तो बदल इतर सगळ्यांच्या कामात मिसळण्याआधी. TDD खात्री करते की tests अस्तित्वात आहेत आणि fail होऊ शकतात; CI खात्री करते की कोणाला लक्षात ठेवावे न लागता त्या चालतात; selection आणि क्रम feedback इतका वेगवान ठेवतात की लोक त्याला वळसा घालण्याऐवजी त्याची वाट पाहतात.

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

exam/lab.py मधील GRACE_TESTS म्हणजे ते पाच प्रश्न; run_grace(fn) ते एका उमेदवार function वर चालवते आणि NotImplementedError ला fail मानते. grace_v0 error देते (red), grace_v1 ही पहिली pass होणारी version, grace_v2 PASS_MARK आणि lift parameter वापरून नियमाला नाव देते. SUITES हे खऱ्या project च्या dependency map चे model आहे: प्रत्येक suite च्या tests ची संख्या आणि तो code चे कोणते भाग चालवतो; select_tests(changed) कोणत्याही बदललेल्या भागाला स्पर्श करणारे suites, त्यांच्या tests ची संख्या आणि एकूण संख्या परत देते.

🧪 करून पाहा

python3 exam/demo.py ci
python3 - <<'EOF'
from exam import lab
for f in (lab.grace_v0, lab.grace_v1, lab.grace_v2):
    print(f.__name__, [("✅" if ok else "❌") for _, ok in lab.run_grace(f)])
for changed in ({"store"}, {"report_card"}, {"grade", "attendance"}):
    picked, n, total = lab.select_tests(changed)
    print(f"changed {sorted(changed)} → {n}/{total} tests from {len(picked)} suites")
EOF
python3 -m unittest discover -s exam/suites -t . 2>&1 | tail -1
python3 exam/demo.py
python3 exam/test_exam.py

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

ci हे छापते:

   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

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

grace_v0 ['❌', '❌', '❌', '❌', '❌']
grace_v1 ['✅', '✅', '✅', '✅', '✅']
grace_v2 ['✅', '✅', '✅', '✅', '✅']
changed ['store'] → 16/105 tests from 2 suites
changed ['report_card'] → 29/105 tests from 2 suites
changed ['attendance', 'grade'] → 93/105 tests from 5 suites

unittest discover OK ने संपते, पूर्ण demo ✅ done — every paper marked ने, आणि checks 12/12 passed ने.

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

Red आधी आले आणि ते महत्त्वाचे ठरले: कोणताही code अस्तित्वात येण्याआधी पाचही प्रश्न fail झाले, म्हणजे ते fail होऊ शकतात. Refactor ने code बदलला पण निकाल नाही — green suite याचसाठी असतो. Selection ने store मधल्या बदलासाठी 105 पैकी फक्त 16 tests ठेवल्या, पण grade आणि attendance ला स्पर्श करणाऱ्या बदलाला 93 लागल्या — बदल छोटे असतील आणि dependency map प्रामाणिक असेल तेव्हा selection सर्वात जास्त वाचवते. E2e suite प्रत्येक बदलासाठी निवडला गेला, कारण तो सगळ्यालाच स्पर्श करतो.

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

आधी code लिहिणे आणि "TDD" tests नंतर, त्याच्या output वरून copy करून
TDD च्या मोठ्या पायऱ्या — एकदम दहा tests, मग तासभर red
refactor वगळणे, त्यामुळे code कायमचा "सर्वात साधी गोष्ट"च राहतो
सर्वात हळू tests आधी चालवणारे, किंवा पहिल्या red नंतरही पुढे चालू राहणारे CI
कुठेही पूर्ण run नसलेले test selection, त्यामुळे चुकीचा dependency map एखादी मोडतोड लपवतो

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

खऱ्या project मध्ये — एक GitHub Actions workflow, .github/workflows/tests.yml, जे या repo च्या checks प्रत्येक push आणि pull request वर, दोन Python versions वर चालवते:

name: tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.10", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: python3 exam/test_exam.py
      - run: python3 -m unittest discover -s exam/suites -t .
      - run: python3 exam/demo.py > out.txt && diff out.txt demo-output.txt

pytest सोबत रोजच्या वापरातले वेग वाढवणारे उपाय:

pytest -x --ff                 # stop at the first failure, run last-failed tests first
pytest -n auto                 # pytest-xdist: one worker per CPU core
pytest --testmon               # pytest-testmon: only tests affected by the changed code

मग test job ला main branch वर required status check बनवा, म्हणजे लाल suite merge अडवेल. CI/CD शाळा याभोवती पूर्ण pipelines बांधते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: push पासून green किंवा red उत्तर मिळेपर्यंतचा वेळ मोजा. दहा मिनिटांपेक्षा कमी असेल तर लोक त्याची वाट पाहतात; तीसपेक्षा जास्त असेल तर वाट पाहणे थांबवतात. वेगवान थर वेगवानच ठेवा, जमेल ते select करा, आणि main च्या आधी सगळे चालवा.

🎓 प्रत्येक प्रश्नपत्रिका तपासली

उशिरा सापडलेला bug जास्त महाग पडतो, आणि सोपे प्रश्न तो चुकवतात → arrange, act, assert, एका वेळी एक प्रश्न → कडा 34.5 वरचा bug शोधतात → नव्या उत्तरपत्रिका प्रश्नांना स्वतंत्र ठेवतात → बदली परीक्षक जे चालवता येत नाही त्याची जागा घेतात — पण खोटे बोलू शकतात → खरा database 67.5 ऐवजी 67 शोधतो → contract नाव-बदल ship होण्याआधीच थांबवतो → end-to-end दिवस थोडे, छोटे प्रश्न खूप → नियम अधिक seed अधिक shrinking स्वतःहून 34.5 शोधतात → mutants दाखवतात की 100% coverage ने काय कधीच तपासले नाही → डुगडुगणारे घड्याळ पक्के केले जाते → आणि CI प्रत्येक बदलावर योग्य प्रश्न विचारते. तुम्ही फक्त testing शिकला नाहीत — आता तुम्ही कोणताही test suite पाहून विचारू शकता: कोणते प्रश्न राहिले आहेत, कोणती उत्तरे अंदाज आहेत, आणि कोणती घड्याळे डुगडुगतात? 📝🧬🎓

⏭️ पुढे

इतर शाळा. CI/CD शाळा या tests खऱ्या pipelines मध्ये चालवते; API शाळा contracts design करते; Database शाळा marks book मध्ये अधिक खोलवर जाते; Observability शाळा tests जे पाहू शकत नाहीत ते पाहते; शाळा portal वर बाकी सगळे आहे.

git checkout main
python3 exam/demo.py     # one last run, for fun

🚦 Lesson 12 — Tests in CI and TDD: red, green, refactor — and the whole picture

📍 You are here: Lesson 12 of 12 · Previous: lesson-11-flaky-tests

📦 What's in this branch

Lessons 01–11, plus when tests run. Test-driven development (TDD) writes the exam question before the answer: red, green, refactor. Continuous integration (CI) runs the suite on every change, fast checks first, and test selection runs only the tests a change can affect. grace_v0, grace_v1, grace_v2, GRACE_TESTS, SUITES and select_tests() in exam/lab.py; ci() in exam/demo.py. And the whole course on one page.

🧒 Explain like I'm 5

A new school rule arrives: "A pupil who is 2 marks or less short of 35, with a medical note, is lifted to 35."

Katrina does something odd. She writes the exam questions first 📝 — five of them: 33 with a note → 35; 34.9 with a note → 35; 33 without a note → 33; 32.9 with a note → 32.9; 35 with a note → 35. She runs them. All five fail — there is no code yet. 🔴 That is red. It proves the questions can fail.

Dipika writes the simplest code that passes. Run again: 5 of 5. 🟢 Green.

Then Dipika tidies it — gives the "2 marks" a name, uses the school's pass-mark constant. Run again: still 5 of 5. 🔵 Refactor done, safely.

And every time anyone changes anything, Aishwarya's CI hall 🚦 runs the questions automatically: the quick ones first, and only the papers that the change could affect. A change to the attendance code runs 28 questions, not all 105. But before anything joins the main branch, every paper is sat.

🗺️ Diagram

flowchart LR
    red["🔴 RED<br/>5 tests first, 0/5 pass"] --> green["🟢 GREEN<br/>simplest code, 5/5"]
    green --> ref["🔵 REFACTOR<br/>name the rule, 5/5"]
    ref -->|"push"| ci["🚦 CI: lint → unit → integration → contract → e2e"]
    ci --> sel["change to attendance<br/>3 of 6 suites, 28 of 105 tests"]
    ci --> main["merge to main<br/>all 105 tests"]

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

❓ What

TDD (test-driven development) — Kent Beck, Test-Driven Development: By Example (2002). A short loop: red (write a failing test for the next small behaviour), green (the simplest code that passes), refactor (clean up with the tests as a safety net). Studies of TDD's effect on defects and speed give mixed results; its clearest benefit is a design you can test, and a suite that exists from day one.
Why red first — a test you never saw fail might not be able to fail (lesson 02's "no assert" mistake).
Continuous integration (CI) — every change is merged often and built and tested automatically on a server (GitHub Actions, GitLab CI, Jenkins, and others).
Fail fast — order the pipeline by speed: lint and type checks (seconds), unit tests, integration, contract, then the few e2e tests. Stop at the first red.
Test selection (test impact analysis) — run only tests that depend on the changed code, using a dependency map (Bazel's build graph), coverage data (pytest-testmon), or a model trained on past failures (Meta's predictive test selection). Always run the full suite somewhere — at merge or nightly — because the map can be wrong.
Parallelism and sharding — split the suite across CPU cores or machines (pytest-xdist, CI matrix jobs). Only safe with independent tests (lesson 04).
Required checks — the repository refuses a merge until the named CI jobs are green.

🤔 Why

Because a test suite only helps if it runs — on every change, before the change joins everyone else's work. TDD makes sure the tests exist and can fail; CI makes sure they run without anyone remembering to; selection and ordering keep the feedback fast enough that people wait for it instead of working around it.

🔧 How (in this repo)

GRACE_TESTS in exam/lab.py are the five questions; run_grace(fn) runs them against a candidate and treats NotImplementedError as a fail. grace_v0 raises (red), grace_v1 is the first passing version, grace_v2 names the rule with PASS_MARK and a lift parameter. SUITES is a model of a real project's dependency map: each suite's test count and the parts of the code it exercises; select_tests(changed) returns the suites that touch any changed part, their test count and the total.

🧪 Try it

python3 exam/demo.py ci
python3 - <<'EOF'
from exam import lab
for f in (lab.grace_v0, lab.grace_v1, lab.grace_v2):
    print(f.__name__, [("✅" if ok else "❌") for _, ok in lab.run_grace(f)])
for changed in ({"store"}, {"report_card"}, {"grade", "attendance"}):
    picked, n, total = lab.select_tests(changed)
    print(f"changed {sorted(changed)} → {n}/{total} tests from {len(picked)} suites")
EOF
python3 -m unittest discover -s exam/suites -t . 2>&1 | tail -1
python3 exam/demo.py
python3 exam/test_exam.py

✅ Verify — what you should see

ci prints:

   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

Your snippet prints:

grace_v0 ['❌', '❌', '❌', '❌', '❌']
grace_v1 ['✅', '✅', '✅', '✅', '✅']
grace_v2 ['✅', '✅', '✅', '✅', '✅']
changed ['store'] → 16/105 tests from 2 suites
changed ['report_card'] → 29/105 tests from 2 suites
changed ['attendance', 'grade'] → 93/105 tests from 5 suites

unittest discover ends with OK, the full demo with ✅ done — every paper marked, and the checks with 12/12 passed.

🏁 What you just proved

Red came first and mattered: the five questions failed before any code existed, so they can fail. The refactor changed the code and not the result — that is what the green suite is for. Selection cut a change to the store down to 16 of 105 tests, but a change touching grade and attendance needed 93 — selection saves most when changes are small and the dependency map is honest. The e2e suite was picked for every change, because it touches everything.

⚠️ Common mistakes

writing the code first and the "TDD" tests after, copied from its output
big TDD steps — ten tests at once, then an hour of red
skipping refactor, so the code stays the "simplest thing" for ever
CI that runs the slowest tests first, or keeps going after the first red
test selection with no full run anywhere, so a wrong dependency map hides a break

🏭 In production

On a real project — a GitHub Actions workflow, .github/workflows/tests.yml, that runs this repo's checks on every push and pull request, on two Python versions:

name: tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.10", "3.12"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: python3 exam/test_exam.py
      - run: python3 -m unittest discover -s exam/suites -t .
      - run: python3 exam/demo.py > out.txt && diff out.txt demo-output.txt

Everyday speed-ups with pytest:

pytest -x --ff                 # stop at the first failure, run last-failed tests first
pytest -n auto                 # pytest-xdist: one worker per CPU core
pytest --testmon               # pytest-testmon: only tests affected by the changed code

Then make the test job a required status check on the main branch, so a red suite blocks the merge. The CI/CD school builds whole pipelines around this.

🏭 Why this matters in production: measure the time from push to a green or red answer. Under ten minutes, people wait for it; over thirty, they stop waiting. Keep the fast layers fast, select what you can, and run everything before main.

🎓 Every paper marked

A bug found late costs more, and easy questions miss it → arrange, act, assert, one question at a time → the edges find the bug at 34.5 → fresh answer sheets keep questions independent → stand-in examiners replace what you cannot run — but can lie → a real database finds 67 instead of 67.5 → a contract stops a rename before it ships → few end-to-end days, many small questions → a rule plus a seed plus shrinking finds 34.5 by itself → mutants show what 100% coverage never checked → the wobbly clock is pinned down → and CI asks the right questions on every change. You didn't just learn testing — you can look at any test suite and ask: which questions are missing, which answers are guesses, and which clocks wobble? 📝🧬🎓

⏭️ Next

The other schools. The CI/CD school runs these tests in real pipelines; the API school designs the contracts; the Database school goes deeper on the marks book; the Observability school watches what tests cannot; the School portal has the rest.

git checkout main
python3 exam/demo.py     # one last run, for fun

← Previousflaky tests Finished! Take the quiz →check what stuck

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