Every developer tests their code. The question is whether they do it by hand — running the script, eyeballing the output, clicking around — or whether a machine does it for them, the same way, every single time, in seconds. Automated tests are small programs that call your code with known inputs and check that the outputs are what you expect. When a test fails, you know exactly what broke and where, before a customer in Pune or a manager in Bengaluru finds out.

Why does this matter so much in real projects?

• Regression protection — the most common bug in a growing codebase is not a new feature that fails; it is an old feature that silently broke when someone changed a shared function. A test suite catches that in the pull request, not in production.
• Confidence to refactor — you cannot clean up a 400-line function you are afraid to touch. With tests, you change it, run pytest, and see green.
• Executable documentation — a test named test_gst_is_18_percent_on_electronics tells the next developer what the code is supposed to do more precisely than a comment ever could.
• Faster feedback — a 2,000-test suite that runs in 30 seconds replaces hours of manual clicking. On a team of five, that is the difference between shipping daily and shipping monthly.

Python ships with unittest in the standard library, but the overwhelming majority of modern Python projects — Django, FastAPI, pandas, NumPy, Home Assistant, and most companies hiring Python developers in India — use pytest. It needs no boilerplate classes, uses plain assert, has a powerful fixture system for setup and teardown, and a plugin ecosystem with over a thousand packages (pytest-cov, pytest-asyncio, pytest-django, pytest-xdist, and many more).

A quick vocabulary before we start, because interviewers love these terms:

• Unit test — tests one function or class in isolation, with external systems replaced by fakes. Fast, numerous.
• Integration test — tests several components together, for example your repository class against a real SQLite database.
• End-to-end (E2E) test — drives the whole application like a user would, for example sending real HTTP requests to a running FastAPI server.

The widely quoted testing pyramid says: many unit tests, fewer integration tests, very few E2E tests. This lecture focuses on unit and integration testing with pytest 9, the current major version, on Python 3.14 (Python 3.15 is the next release in line; everything here works on 3.12 and later).

Install pytest into your project's virtual environment. If you use uv (recommended in this course), add it as a development dependency so it does not ship with your application. With plain pip, activate your venv and install it directly.

A pytest test is just a function whose name starts with test_ inside a file whose name starts with test_ or ends with _test.py. Inside it you use the ordinary Python assert statement. That is the entire API for a basic test — no base class, no self.assertEqual.

How test discovery works. When you run pytest with no arguments, it starts from the current directory (or the testpaths you configure) and recursively collects:

• files matching test_*.py or *_test.py;
• inside them, functions prefixed test;
• classes prefixed Test that have no __init__ method, and test-prefixed methods inside them.

Everything else is ignored, so helper modules such as conftest.py or factories.py are never run as tests. You can also target a specific file (pytest tests/test_gst.py), a specific test (pytest tests/test_gst.py::test_electronics_rate), or a keyword expression (pytest -k "gst and not slow").

Reading the output. A dot . means pass, F means fail, E means an error during setup, s means skipped, x means an expected failure. Useful flags you will use daily: -v for verbose names, -x to stop at the first failure, -q for quiet output, --lf to re-run only the tests that failed last time, and -s to show print() output (pytest captures stdout by default).

In the example below we test a tiny GST calculator. Note the layout: application code lives in src/shop/, tests live in tests/, and the project is installed in editable mode so that from shop.gst import ... works from anywhere.

In unittest you must remember a dozen methods: assertEqual, assertIn, assertTrue, assertAlmostEqual, assertRaises. In pytest you write a plain assert and pytest does something clever called assertion rewriting: when it imports your test module, it rewrites the bytecode of every assert so that, on failure, it can show the intermediate values of the expression. This is called assertion introspection, and it is the single feature that converts most people to pytest.

Compare the two failure messages. With unittest, AssertionError: 1180 != 1181 tells you the numbers. With pytest you also get the expression, the actual values of each variable, and for collections a line-by-line diff: which key is missing from a dict, which item differs in a list, where two long strings diverge. For large structures pytest truncates the output; add -vv to see everything.

Patterns worth knowing:

• Floating point — never assert 0.1 + 0.2 == 0.3 (it is False). Use pytest.approx(0.3), which compares with a relative tolerance of 1e-6 by default and also works on lists and dicts of floats.
• Membership and containment — assert "Mumbai" in cities, assert {"id": 1}.items() <= record.items() to check a subset of keys.
• Custom message — assert balance >= 0, f"balance went negative: {balance}". The message is appended to pytest's own introspection, not replacing it.
• Multiple assertions — a test stops at the first failed assert. That is usually what you want (one reason to fail per test). If you need to see all failures at once, the pytest-check plugin provides soft assertions.

Important: assertion rewriting only applies to test modules and conftest.py files that pytest imports itself. If you put helper assertions in a separate module, register it with pytest.register_assert_rewrite("tests.helpers") in conftest.py, or you will lose the rich output.

Most tests need some prepared state before they run: a database connection, a sample customer object, a temporary directory, an HTTP client. In unittest you write setUp and tearDown methods on a class. pytest replaces this with fixtures: functions decorated with @pytest.fixture whose return value is injected into any test that names the fixture as a parameter. This is dependency injection by argument name, and it is why pytest tests read so cleanly.

Teardown with yield. If the fixture needs cleanup (close a connection, delete a file), write it as a generator: everything before yield is setup, the yielded value goes to the test, and everything after yield runs as teardown — even if the test failed.

Scopes control how often a fixture runs. The scope argument accepts:

• "function" (default) — fresh instance for every test. Safest; use for anything mutable.
• "class" — once per test class.
• "module" — once per test file.
• "package" — once per package directory.
• "session" — once for the whole pytest run. Use for expensive, read-only resources such as a Docker database container, a compiled model, or a parsed 50 MB fixture file.

A higher-scoped fixture must never depend on a lower-scoped one (a session fixture cannot request a function fixture) — pytest raises a ScopeMismatch error if you try.

conftest.py is a special file that pytest loads automatically. Fixtures defined there are available to every test in that directory and below, with no import statement. A tests/conftest.py typically holds your shared fixtures; a deeper tests/api/conftest.py can add or override fixtures for just that sub-folder.

autouse=True makes a fixture run for every test in scope without being requested — handy for resetting a global cache or freezing time, but use it sparingly because it hides dependencies.

Fixtures can use other fixtures, which lets you build layers: db_connection (session) → db_session (function, rolls back after each test) → sample_customer (function, inserts one row). Run pytest --fixtures to list every fixture available, including the built-in ones like tmp_path, monkeypatch, capsys and caplog.

Suppose you want to test price_with_gst for five categories. Copy-pasting five near-identical test functions is tedious and, worse, when the behaviour changes you must edit all five. Parametrization lets you write the test once and supply a table of inputs and expected outputs; pytest generates one independent test per row, each with its own pass/fail status and its own readable ID like test_gst[electronics-1180.00].

The decorator takes two things: a string of comma-separated argument names, and a list of tuples (or single values when there is one argument). Use ids=[...] to give rows human-readable names, or wrap a row in pytest.param(..., id="negative-price") to name it inline. pytest.param also accepts marks=pytest.mark.xfail for rows that are known to fail — useful for documenting a bug you have not fixed yet.

Stacking decorators produces the cartesian product: two parametrize decorators with 3 and 4 values yield 12 tests. This is how you test every combination of, say, payment method and currency.

Parametrizing fixtures. A fixture itself can be parametrized with @pytest.fixture(params=[...]); every test that requests it then runs once per parameter. This is how you run the same repository tests against SQLite and PostgreSQL, or the same API tests against two client implementations. Inside the fixture, read the current value from request.param.

Good parametrization habits:

• Keep each row a distinct, meaningful case (boundary values, zero, negative, empty, Unicode), not random filler.
• Prefer explicit expected values over computing the expected value with the same logic as the code under test — otherwise a bug in the formula passes the test.
• When rows get long, move the table into a module-level constant so the decorator stays readable.

Correct code does not just produce correct results; it fails correctly — raising the right exception, with a useful message, when given bad input. Tests for this use the pytest.raises context manager. The block inside with pytest.raises(ValueError): must raise ValueError (or a subclass); if nothing is raised, or a different exception is raised, the test fails.

Three refinements make exception tests precise:

• match= takes a regular expression that is searched (re.search) against str(exception). match="negative" passes for the message "base_price cannot be negative". Use re.escape when the message contains regex metacharacters like parentheses or dots.
• as excinfo captures an ExceptionInfo object so you can assert on attributes after the block: excinfo.value is the exception instance, excinfo.type is its class, and excinfo.value.__cause__ lets you check exception chaining from raise ... from ....
• Keep the block small. Only the line expected to raise should be inside with pytest.raises. If you wrap ten lines, an unrelated ValueError on line two would make the test pass for the wrong reason.

Warnings are tested the same way with pytest.warns(DeprecationWarning, match=...). And for Python 3.11+ exception groups (which you met in the asyncio lecture, where a TaskGroup raises ExceptionGroup), pytest 8.4 and later provide pytest.RaisesGroup, which checks that a group contains the expected member exceptions.

A subtle but common requirement is testing that a function does not raise. You do not need a special construct — simply call it; any exception fails the test automatically.

Real code talks to things you do not want in a unit test: the system clock, environment variables, the network, payment gateways, random numbers. A test that calls the live Razorpay API is slow, flaky, costs money, and cannot run offline. Test doubles replace those dependencies with controllable stand-ins. pytest gives you two tools, and knowing when to use which is an interview favourite.

monkeypatch (pytest built-in fixture) temporarily changes attributes, dictionary items, environment variables or the working directory, and automatically undoes every change when the test ends. Its methods are setattr, delattr, setitem, delitem, setenv, delenv, syspath_prepend and chdir. It is the simplest option when you just need to swap one function or variable for a plain replacement — for example replacing datetime.now with a function that returns a fixed date, or setting DATABASE_URL for the duration of a test.

unittest.mock (standard library) provides Mock, MagicMock, AsyncMock (for coroutines) and the patch helper. A mock object accepts any call and records it, so you can assert how your code interacted with the dependency: mock.assert_called_once_with(amount=500, currency="INR"). Use return_value to script the reply, side_effect to raise an exception or return different values on successive calls, and spec=SomeClass so that calling a method that does not exist on the real class fails instead of silently passing.

The golden rule of patching: patch where the name is looked up, not where it is defined. If shop/payments.py does from razorpay import Client, you must patch shop.payments.Client, not razorpay.Client, because the module already holds its own reference.

A cleaner alternative to patching is dependency injection: let the function accept the client as a parameter (with a sensible default) so tests can pass a fake directly. The example shows both approaches side by side. Prefer injection for your own code; reach for patch when testing code you cannot restructure.

Code that reads or writes files is awkward to test: you do not want tests to litter the project directory, collide with each other, or depend on files that exist only on your laptop. pytest's tmp_path fixture solves this by handing each test a brand-new, empty directory as a pathlib.Path. The directory lives under the system temp folder (for example /tmp/pytest-of-ravindra/pytest-42/test_export_csv0/), is unique per test, and pytest keeps only the last three runs so you can inspect files after a failure.

Because it is a Path, you use the pathlib API you learned earlier: tmp_path / "report.csv", .write_text(), .read_text(), .mkdir(), .exists(). There is also tmp_path_factory, a session-scoped fixture, for when a large file should be generated once and shared read-only across many tests. (You may see tmpdir in older code; it returns a legacy py.path object — prefer tmp_path.)

Two more built-in fixtures round out the "capture" toolbox:

• capsys captures everything written to sys.stdout and sys.stderr. Call captured = capsys.readouterr() and assert on captured.out. This is how you test CLI tools and print-based reports.
• caplog captures log records emitted through the logging module. You can assert on caplog.records, caplog.text, or set the level with caplog.set_level(logging.DEBUG). Testing that your code logs a warning when a payment is retried is a genuine production requirement — monitoring alerts depend on those messages.

Combined with monkeypatch.chdir(tmp_path), you can test code that writes to "the current directory" without ever touching your real project files.

Passing tests tell you that the code you exercised works. Coverage tells you which code you never exercised at all. The pytest-cov plugin wraps the coverage.py library and reports, per file, the percentage of lines (and optionally branches) that ran during the test session.

Install it with uv add --dev pytest-cov and run pytest --cov=shop --cov-report=term-missing. The --cov=shop argument names the package to measure (use your package name, not tests); term-missing prints the line numbers that were not executed, which is exactly the list you need to decide what to test next. Other report formats: html produces a browsable htmlcov/index.html with red/green highlighted source; xml produces the file that CI dashboards and tools such as Codecov or SonarQube ingest.

Branch coverage (--cov-branch) is stricter than line coverage: an if statement counts as fully covered only when both the true and false paths ran. A function with if discount: price -= discount can have 100% line coverage while the "no discount" branch was never tested.

Enforce a floor with --cov-fail-under=85: the run exits non-zero when coverage drops below 85%, which makes a CI pipeline fail. Put the number in pyproject.toml under [tool.coverage.report] so the whole team shares it.

What coverage is not. A line that ran is not a line that was *verified*. A test that calls price_with_gst and asserts nothing gives 100% coverage and catches zero bugs. Treat coverage as a map of the untested territory, not as a quality score; 80–90% with meaningful assertions beats 100% with hollow ones. Exclude genuinely untestable lines (if __name__ == "__main__":, abstract methods, TYPE_CHECKING blocks) with exclude_also patterns rather than writing fake tests for them.

A test suite is code: it needs structure or it rots. The layout used throughout this lecture is the modern src layout, which most Python packaging guides recommend:

• src/shop/ — the package. Because it is not on the path by default, tests can only import it after uv sync or pip install -e . installs it, which guarantees you test the installed package, exactly as users will.
• tests/ — mirrors the package: tests/test_gst.py tests src/shop/gst.py. For bigger projects add sub-folders: tests/unit/, tests/integration/, tests/e2e/, each with its own conftest.py.
• tests/conftest.py — shared fixtures; no __init__.py is needed in tests/ with the default importmode=prepend, but you must avoid two test files with the same basename in different folders unless you add __init__.py files or set --import-mode=importlib.

Naming tests is a skill. test_1 is useless; test_refund_after_30_days_is_rejected tells a reader the rule being protected. A common pattern is Arrange–Act–Assert: set up data, call the function, check the result, separated by blank lines.

Markers label tests so you can select or skip them. Built-in markers: @pytest.mark.skip(reason=...), @pytest.mark.skipif(sys.platform == "win32", reason=...), @pytest.mark.xfail(raises=NotImplementedError). Custom markers such as slow, integration or external must be registered in configuration, otherwise pytest warns about unknown marks (--strict-markers turns the warning into an error, which you want). Then run pytest -m "not slow" locally and the full suite in CI.

Configuration lives in pyproject.toml under [tool.pytest.ini_options]. The most useful keys: testpaths (where to look), addopts (flags applied to every run), markers (registrations), filterwarnings (turn deprecation warnings into errors so you notice them), and xfail_strict (an xfail test that unexpectedly passes becomes a failure, so you remove stale marks).

Finally, speed: install pytest-xdist and run pytest -n auto to spread tests across all CPU cores — a 4-minute suite often drops to under a minute. That only works if tests are independent, which is one more reason to avoid shared mutable state.

In the previous lecture you wrote async def functions and ran them with asyncio.run(). A test function declared with async def is a coroutine; plain pytest does not know how to run it and will skip it with a warning ("async def functions are not natively supported"). You need a plugin that provides an event loop. The two popular choices are pytest-asyncio (the most widely used; install with uv add --dev pytest-asyncio) and anyio (which comes with pytest support and also works with Trio).

With pytest-asyncio there are two modes:

• strict mode (default) — every async test must be decorated with @pytest.mark.asyncio, and async fixtures with @pytest_asyncio.fixture. Explicit, but noisy.
• auto mode — set asyncio_mode = "auto" in [tool.pytest.ini_options] and every async def test_... is run automatically, with ordinary @pytest.fixture working for async fixtures too. Most projects choose this.

Async fixtures work like sync ones: async def with yield for teardown, so you can open an httpx.AsyncClient once and close it after the test. Note that the event loop is function-scoped by default; a session-scoped async fixture needs loop_scope="session" on the fixture and the tests, otherwise you get "attached to a different loop" errors.

Mocking coroutines uses unittest.mock.AsyncMock (Python 3.8+). Calling it returns an awaitable, so await fake.fetch() works and fake.fetch.assert_awaited_once_with(...) verifies the interaction. A plain MagicMock would return a non-awaitable and crash with "object MagicMock can't be used in 'await' expression" — a very common error.

Testing timeouts and concurrency. Use asyncio.timeout() inside tests to make a hung coroutine fail fast rather than hanging the whole suite, and when testing a function that uses asyncio.gather, inject fakes with different delays to verify that it really runs concurrently (total time close to the slowest call, not the sum). The example tests a price-aggregator that fetches rates from several suppliers concurrently.

Tests that run only on your laptop protect only your laptop. Continuous Integration (CI) runs the test suite automatically on every push and pull request, on a clean machine, so "it works on my machine" is never the final word. GitHub Actions is free for public repositories and included in private ones with generous limits, which makes it the default for most Indian startups and open-source projects.

A workflow is a YAML file in .github/workflows/. The one below does what a professional Python pipeline needs:

• Triggers on pushes to main and on every pull request.
• Matrix — runs the suite on Python 3.12, 3.13 and 3.14 in parallel, so you learn immediately if a new interpreter breaks something. Add os to the matrix to cover Windows and macOS as well.
• Checkout and setup — actions/checkout fetches the code; astral-sh/setup-uv installs uv and enables caching of the dependency download, which cuts a 60-second install to a few seconds on repeat runs.
• Install — uv sync creates the environment from uv.lock, so CI uses exactly the versions you tested locally. With pip you would run pip install -e ".[dev]" instead.
• Test with coverage — uv run pytest --cov --cov-report=xml; the fail_under in pyproject.toml makes the job fail if coverage regresses.
• Upload the report as an artifact (or to Codecov) so reviewers can see it on the pull request.

Once the workflow is green, enable branch protection on main so that a pull request cannot be merged until the "tests" check passes. That single setting is what turns a test suite from a good habit into an enforced quality gate. Add a linting step (ruff check . and ruff format --check .) in the same job; on larger projects split lint and test into separate jobs so they run in parallel.

Keep CI fast: cache dependencies, run pytest -n auto, mark genuinely slow integration tests and run them on a nightly schedule (on: schedule) rather than on every commit. A pipeline that takes 15 minutes gets ignored; one that takes 2 minutes gets trusted.

Here is how the pieces from this lecture combine in the kinds of projects you will actually work on.

1. FastAPI backend (next lecture). Every endpoint gets tests through httpx.AsyncClient with ASGITransport, so requests hit the app in-process without a running server. A client fixture builds the app with dependency overrides that swap the real PostgreSQL session for a SQLite or transactional test session. Parametrized tests cover validation errors (422), authentication (401/403) and the happy path. This is the standard pattern in fintech and SaaS teams across Bengaluru and Hyderabad.

2. Data pipelines with pandas. A fixture returns a small, hand-written DataFrame with the edge cases that matter (missing values, duplicate IDs, a negative amount). Transformations are tested with pandas.testing.assert_frame_equal, and the raw CSV is read from tmp_path so the test never depends on a file on someone's laptop. Coverage reveals the except branches that no sample data ever triggers.

3. Scheduled jobs and notifications. A nightly job that sends reminder SMS to customers is tested with monkeypatch to freeze "today", a MagicMock SMS client to capture what would have been sent, and caplog to assert that failures are logged with the customer ID for later retry.

4. Library and SDK maintainers. Open-source packages run a matrix across four Python versions and three operating systems in GitHub Actions, use xfail for known upstream bugs, and --strict-markers and filterwarnings = error to catch deprecations before users do.

5. Legacy code rescue. When a team inherits an untested 20,000-line Django monolith, the practical approach is characterization tests: write tests that capture the current behaviour (even the odd parts), get coverage up on the modules you need to change, then refactor safely. pytest's --lf and -x flags make this iterative loop fast.

6. Interview take-home assignments. Candidates who submit a solution with a tests/ folder, a pyproject.toml with pytest configured, and a green CI badge stand out immediately — it signals professional habits more than any single algorithm answer.

In each of these, note the shared discipline: tests are fast and isolated, external systems are faked at the boundary, and CI enforces the result.

1. Tests that depend on each other. Test A creates a record, test B assumes it exists. The suite passes in order and fails with -n auto or -p randomly. Fix: every test builds its own state through fixtures; use a transaction-rollback fixture for databases.

2. Patching the wrong target. patch("requests.get") has no effect because shop/api.py imported get directly. Fix: patch where it is used — patch("shop.api.get") — or inject the dependency.

3. Using MagicMock for async code. await fake.fetch() crashes with "can't be used in 'await' expression". Fix: use AsyncMock, and assert with assert_awaited_once_with.

4. Mutable default or module-level fixture data. A list returned by a session-scoped fixture is mutated by one test and poisons the rest. Fix: keep mutable fixtures function-scoped, or return a fresh copy.

5. A huge with pytest.raises block. The test passes because *some* line raised, not the one you meant. Fix: put only the single call inside the block, and use match=.

6. Comparing floats with ==. assert total == 4366.0 fails intermittently after a refactor changes the order of multiplication. Fix: pytest.approx, or use Decimal for money.

7. Asserting nothing. A test that only calls the function gives coverage but no protection. Fix: every test asserts on the return value, a side effect, or a raised exception.

8. Forgetting to register custom markers. PytestUnknownMarkWarning is ignored, then a typo like @pytest.mark.slwo silently stops a test from being excluded. Fix: register markers in pyproject.toml and enable --strict-markers.

9. Unawaited coroutine in a test. Writing cheapest_rate("pen", fetchers) without await means the function never runs and the assertion compares a coroutine object. Fix: watch for RuntimeWarning: coroutine ... was never awaited and turn warnings into errors.

10. Tests that hit the real network or clock. They are slow, fail offline and break at midnight or on month boundaries. Fix: fake the boundary with monkeypatch, AsyncMock or a fake client; test the real integration separately with an integration marker.

11. ImportError: No module named 'shop'. The src layout requires the package to be installed. Fix: uv sync or pip install -e .; do not hack sys.path in conftest.py.

12. Leaving print debugging in tests and wondering why nothing shows. pytest captures output. Fix: run with -s, or better, use capsys and assert on the output; use breakpoint() with --pdb for real debugging.

What is the difference between pytest and unittest in Python?

unittest is in the standard library and follows the classic xUnit style: test classes inheriting from TestCase, setUp/tearDown methods, and self.assertEqual-style methods. pytest uses plain functions and plain assert with automatic introspection, has a far more flexible fixture system with scopes and dependency injection, supports parametrization natively, and has a large plugin ecosystem. pytest can also run existing unittest test cases, so migration is gradual.

How does pytest discover tests?

It recursively scans the directories in testpaths (or the current directory) for files named test_*.py or *_test.py, then collects test-prefixed functions and test-prefixed methods inside Test-prefixed classes that have no __init__. You can change these rules with python_files, python_classes and python_functions in configuration.

What is a fixture in pytest and when should I use one?

A fixture is a function decorated with @pytest.fixture that provides setup (and, via yield, teardown) for tests. A test receives it by naming it as a parameter. Use fixtures for anything more than one test needs: sample data, database sessions, temporary directories, HTTP clients. Put shared fixtures in conftest.py.

What is the difference between monkeypatch and unittest.mock?

monkeypatch is a pytest fixture for temporarily replacing attributes, dict items, environment variables or the working directory, with automatic restoration. unittest.mock provides mock objects (Mock, MagicMock, AsyncMock) that record calls, and patch for replacing targets. Use monkeypatch to swap a simple value or function; use mocks when you need to assert how the dependency was called.

How do I test that a function raises an exception in pytest?

Wrap only the call in with pytest.raises(ExceptionType, match="regex"):. Capture the exception with as excinfo if you need to inspect excinfo.value or its __cause__.

How do I test async functions with pytest?

Install pytest-asyncio (or use anyio), set asyncio_mode = "auto", and write async def test_... functions. Replace awaited dependencies with unittest.mock.AsyncMock.

How much code coverage is good enough?

There is no magic number. Most teams set fail_under between 80 and 90 percent and care more about covering the branches that carry business risk (money, authentication, data loss) than about reaching 100%. Coverage shows what is untested; it does not prove what is tested is correct.

How do I run only one test or only failed tests in pytest?

pytest path/to/test_file.py::test_name runs one test; pytest -k "keyword" selects by name; pytest --lf re-runs only the last failures; pytest -x stops at the first failure.

Q1. Explain how pytest's assertion introspection works.

pytest installs an import hook that rewrites the AST of test modules at import time, replacing each assert with code that evaluates sub-expressions and stores their values. When an assertion fails, pytest prints the expression together with the intermediate values and a diff for collections. It applies to test files and conftest.py; other modules need pytest.register_assert_rewrite.

Q2. What are fixture scopes, and what is the risk of using session scope?

Scopes (function, class, module, package, session) control how often a fixture is created and torn down. Session scope saves time for expensive resources but shares one instance across all tests, so any mutation leaks between tests and creates order-dependent failures. Use it only for immutable or externally reset resources, and never let a session fixture depend on a function-scoped one.

Q3. What is the difference between a mock, a stub and a fake?

A stub returns canned answers (return_value). A mock additionally records calls so you can assert on interactions (assert_called_once_with). A fake is a working lightweight implementation, such as an in-memory repository replacing a database. unittest.mock objects can act as stubs or mocks; fakes are classes you write yourself.

Q4. Why must you patch "where the name is used" rather than "where it is defined"?

from x import y copies the reference y into the importing module's namespace at import time. Patching x.y later changes only x's attribute; the importing module still holds the original. You must patch the name in the module under test.

Q5. How does @pytest.mark.parametrize differ from a loop inside a test?

Parametrize generates separate test items, each reported independently with its own ID; one failing case does not hide the others, and you can rerun a single case. A loop inside one test stops at the first failed assertion and reports as one test.

Q6. What is TDD, and what are its three steps?

Test-Driven Development: write a failing test first (Red), write the minimum code to make it pass (Green), then improve the design while keeping tests green (Refactor). It forces small steps, testable design and a suite that reflects requirements.

Q7. What does conftest.py do?

It is a per-directory plugin file that pytest loads automatically. It holds shared fixtures, hooks (such as pytest_addoption or pytest_collection_modifyitems) and assertion-rewrite registrations, and its fixtures are visible to every test in the same directory tree without imports.

Q8. How would you make a flaky test suite reliable?

Find order dependence by shuffling (pytest-randomly) and running in parallel (-n auto); remove shared mutable state; fake time, randomness and network at the boundary; set explicit timeouts for async code; avoid sleep-based synchronization; and quarantine genuinely slow integration tests behind markers.

Q9. What is the difference between xfail and skip?

skip does not run the test at all (for example, platform-specific code). xfail runs it and expects it to fail, documenting a known bug; with strict=True, an unexpected pass is reported as a failure so you remember to remove the mark.

Q10. How do you test code that uses the current time?

Inject a clock function as a parameter, or use monkeypatch to replace datetime in the module under test with a subclass whose now() returns a fixed value. Libraries like freezegun or time-machine automate this across the whole process.

You will now build a small prepaid wallet module — the kind that powers a food-delivery app's credit balance — using Test-Driven Development. TDD is a loop of three steps, repeated every few minutes:

1. Red — write one small test for behaviour that does not exist yet. Run pytest; it must fail (if it passes, the test is not testing anything new).
2. Green — write the simplest code that makes that test pass. Resist the urge to build ahead.
3. Refactor — with the tests green, improve names, remove duplication, tighten types. Run pytest again.

Why work this way? You never write untested code, you design the API from the caller's point of view (the test is the first caller), and you get a regression suite for free. In practice, teams mix TDD with test-after; what matters is that the tests exist and are meaningful.

Requirements for the wallet:

• It starts with a zero balance in paise (integers avoid float money bugs).
• top_up(amount) adds money; amounts must be positive and at most ₹50,000 (5,000,000 paise) per transaction.
• pay(amount, note) deducts money; it must raise InsufficientBalance if the balance is too low, and record a transaction.
• Every transaction is stored with a timestamp obtained from an injectable clock so tests are deterministic.
• statement() returns the transactions in order, and export_statement(path) writes them as CSV.

Your steps:

1. Create the project: uv init shop-wallet && cd shop-wallet && uv add --dev pytest pytest-cov. Create src/wallet/__init__.py (the [tool.pytest.ini_options] block from section 10 goes in pyproject.toml).
2. Copy the test file below into tests/test_wallet.py and comment out all but the first test. Run pytest — Red.
3. Write just enough in src/wallet/core.py to pass it — Green. Uncomment the next test. Repeat.
4. When all tests pass, run pytest --cov=wallet --cov-report=term-missing. Aim for 100% on this small module, and add a test for any line reported as missing.
5. Add the GitHub Actions workflow from section 12, push to GitHub, and watch the green check appear.

The complete reference implementation is included after the tests so you can check your work — but only after you have tried the Red–Green–Refactor loop yourself.

• Automated tests protect against regressions, enable fearless refactoring and document behaviour; pytest is the de-facto standard Python test framework.
• pytest discovers test_*.py files and test_-prefixed functions automatically; run one file, one test, or a -k expression; use -x, --lf, -v and -s daily.
• Plain assert plus assertion rewriting gives rich failure output; use pytest.approx for floats and Decimal for money.
• Fixtures inject setup via parameter names, tear down after yield, and come in function, class, module, package and session scopes; share them in conftest.py.
• @pytest.mark.parametrize turns a table of cases into independent tests; stacked decorators multiply; fixtures can be parametrized too.
• Test failures with pytest.raises(..., match=), inspect the exception through excinfo, and keep the with block to a single call.
• Isolate external systems with monkeypatch (attributes, env vars, cwd) and unittest.mock (MagicMock, AsyncMock, patch); patch where the name is used; prefer dependency injection.
• Use tmp_path for file I/O, capsys for printed output and caplog for log records.
• pytest-cov measures line and branch coverage; enforce a floor with fail_under, read term-missing to find untested code, and remember that coverage is not correctness.
• Organise with the src layout, register markers, configure everything in pyproject.toml, and parallelise with pytest-xdist.
• Test async code with pytest-asyncio in auto mode and AsyncMock; guard against hangs with asyncio.timeout.
• TDD: Red → Green → Refactor in small steps.
• GitHub Actions runs the suite on every push across a Python version matrix; branch protection makes it a real quality gate.

Next lecture: Building REST APIs with FastAPI