← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🧑‍🏫 Mocks vs fakes — lesson 05

⏮️ Before test doubles

Unit tests called the real service over the network — slow, and red whenever it was down.

✅ फायदे

  • mock: checks exact calls; quick to write with unittest.mock
  • fake: real behaviour, tests stay green through refactors

❌ तोटे

  • mock: breaks when the code is refactored; can repeat the code line by line
  • fake: someone must maintain it and keep it honest

👍 वापरा जेव्हा

  • mocks at the edge of your system: 'was the email sent?'
  • fakes for your own repositories and services

👎 दोनदा विचार करा जेव्हा

  • mocking objects you own and could just use
  • a fake nobody checks against the real thing

🔌 Fakes vs a real database — lesson 06

⏮️ Before in-memory and container databases

A shared test database that every developer and CI job wrote to at once.

✅ फायदे

  • fake: microseconds, no setup
  • real database: real SQL, types and constraints (67 vs 67.5, IntegrityError)

❌ तोटे

  • fake: cannot show SQL bugs
  • real database: slower; needs the SAME engine as production to be honest

👍 वापरा जेव्हा

  • fakes for business logic around the store
  • a real engine (SQLite in memory, Testcontainers) for every query that computes

👎 दोनदा विचार करा जेव्हा

  • SQL tested only through a mock of the driver
  • SQLite in tests when production runs PostgreSQL, for engine-specific SQL

🤝 Contract tests vs end-to-end tests — lessons 07, 08

⏮️ Before contracts

A shared staging environment where every team's latest version ran together — and was usually broken.

✅ फायदे

  • contract: fast, runs in each team's own pipeline, names the broken field
  • e2e: proves the real wiring, as a user sees it

❌ तोटे

  • contract: only checks what consumers wrote down; says nothing about behaviour
  • e2e: slow, flaky, and a failure rarely says where

👍 वापरा जेव्हा

  • contracts between every consumer and provider team
  • a few e2e tests on the critical journeys

👎 दोनदा विचार करा जेव्हा

  • contracts as a replacement for the provider's own functional tests
  • e2e tests as the only check between services

🔺 Test pyramid vs testing trophy — lesson 08

⏮️ Before either shape

The ice-cream cone: mostly manual and UI tests — in the model, 1005 s a run and red for no reason 87% of the time.

✅ फायदे

  • pyramid: fastest feedback, precise failures (60.0 s, 17% in the model)
  • trophy: tests closer to real use, more confidence per test

❌ तोटे

  • pyramid: many unit tests can mirror the code and miss the wiring
  • trophy: slower (80.8 s, 23% in the model); needs fast integration tools

👍 वापरा जेव्हा

  • pyramid for logic-heavy code: rules, calculations, parsers
  • trophy for UI and glue code where the wiring is the risk

👎 दोनदा विचार करा जेव्हा

  • either shape with many e2e tests
  • arguing shapes instead of measuring your own suite

🧬 Line coverage vs mutation score — lesson 10

⏮️ दोन्हीपैकी काहीही येण्याआधी

'We have lots of tests' — nobody knew what they checked.

✅ फायदे

  • coverage: cheap, finds code that never ran
  • mutation: measures whether tests would NOTICE a bug (4/10 vs 9/10)

❌ तोटे

  • coverage: 100% with no asserts is possible
  • mutation: slow — the suite runs once per mutant; equivalent mutants need a human

👍 वापरा जेव्हा

  • coverage as an alarm in every CI run
  • mutation testing on critical modules, on changed code or nightly

👎 दोनदा विचार करा जेव्हा

  • a coverage percentage as the quality goal
  • mutation testing the whole code base on every commit

🚦 Test-first (TDD) vs test-after — lesson 12

⏮️ Before automated tests

Code was written, then tested by hand once, then never again.

✅ फायदे

  • test-first: every test was seen failing; design is testable from day one
  • test-after: fast for exploring and spikes

❌ तोटे

  • test-first: awkward when you do not yet know what to build
  • test-after: tests copied from the code's output check the bugs too

👍 वापरा जेव्हा

  • TDD for rules and bug fixes (write the failing test for the bug first)
  • test-after for prototypes that will be thrown away — then add tests before keeping them

👎 दोनदा विचार करा जेव्हा

  • 'TDD' with ten tests written at once
  • shipping a prototype with no tests at all