Testing with pytest: Fixtures, Parametrize, FastAPI

How to read this: the order is measured, not assumed; a lesson test runs a throw-away file in a child pytest and checks it.

A fixture in conftest.py is visible only to tests in that folder and below. The lesson folder's conftest.py imports the capstone's three fixtures.

In the interview: "How do you keep tests independent but fast?" A good answer: build expensive, read-only objects once at a wide scope, build anything a test can change per test, never depend on order.

Parametrize: one test, a table of cases

The pytest documentation shows @pytest.mark.parametrize("test_input,expected", [...]) and a failure reported as test_eval[6*9-42]: by default the id is built from the values. The ids argument gives readable names instead:

Verified: capstone/fde-product-discovery-copilot/lessons/M1-L6/test_m1_l6_solution_clarify.py

@pytest.mark.parametrize(
    "fields, expected",
    [
        ({}, False),  # nothing at all
        ({"category": "sensors"}, False),  # a category alone is not enough
        ({"keywords": ["vibration"]}, False),  # a detail without a category is not enough
        ({"category": "sensors", "keywords": ["vibration"]}, True),
        ({"category": "gateways", "protocols": ["OPC UA"]}, True),
        ({"skus": ["LUM-VS-100"]}, True),  # a named product is enough on its own
    ],
    ids=["empty", "category-only", "detail-only", "category-and-keyword", "category-and-protocol", "named-sku"],
)
def test_is_specific_enough(fields: dict[str, object], expected: bool) -> None:
    assert is_specific_enough(Requirements(**fields)) is expected  # type: ignore[arg-type]

When the detail-only case fails, the report names it. Add a case by adding a line, not a test.

Endpoints, and a model you control

TestClient is built on httpx. FastAPI's documentation stresses that the tests are plain def and the calls are not awaited.

For the model, the capstone's tests use hand-written doubles in tests/helpers.py, with no mocking framework:

Verified: capstone/fde-product-discovery-copilot/tests/helpers.py

class ScriptedProvider:
    """Returns the given texts in order, whatever the prompt. Records every call."""

    name = "scripted"

    def __init__(self, texts: list[str]) -> None:
        self.texts = list(texts)
        self.calls: list[list[Message]] = []

    def complete(self, messages: Sequence[Message], schema: dict[str, Any] | None = None) -> Completion:
        self.calls.append(list(messages))
        return Completion(self.texts.pop(0), 10, 5)

texts scripts a model that returns broken JSON first and valid JSON second; calls shows what the pipeline sent. FastAPI also offers app.dependency_overrides; the capstone does not use Depends, so it passes its replacement in when it builds Services.

Worked example

A developer breaks three things. Which test fails, and in which layer?

Assumptions: test names are from the capstone; the three changes are thought experiments, not edits made to it.

Run the capstone's suite and read the last line (count as of 2026-11-02; the time depends on your machine):

./.venv/Scripts/python -m pytest tests

151 passed in 11.96s

Build it

From capstone/fde-product-discovery-copilot:

./.venv/Scripts/python -m pytest lessons/M1-L6

1. In test_m1_l6_fixtures_tour.py find the fixture-order test: it runs a child pytest on a small file.
2. Change scope="module" in the CHILD source to the default and see which assertion fails.
3. Add a seventh case to test_is_specific_enough, break is_specific_enough on purpose and read the failure's id.
4. Run one test by name: pytest lessons/M1-L6 -k fresh_app.

Exercise

Write tests for app/clarify.py at three layers, without changing app/.

Acceptance criteria:

• One parametrized test for is_specific_enough: at least five cases, readable ids.
• Tests that the first question asks for a category when none is known, that never more than MAX_QUESTIONS questions come back, and that a known quantity and budget are not asked again.
• One API test with the client fixture: a vague request returns 200, no recommendations and one to three open questions.

Done when all the tests pass, and at least one fails if you change is_specific_enough to return True for a bare category.

Common mistakes

• Tests that call the real network or model. They are slow, cost money and fail on a bad day. Replace the provider and pass a fake transport.
• Everything at session scope. A shared object a test mutates passes alone and fails in another order. Widen scope only for read-only objects.
• One giant test with many asserts. The first failing assert hides the rest. Parametrize so every case reports.
• Asserting on a model's exact words. Assert on structure, ids and rules; the mock is a rule-based stand-in, not a model.

Knowledge check

You can now

• Choose the cheapest test layer that can catch a given bug.
• Write fixtures with the right scope and tear-down.
• Cover a table of cases with one parametrized test and readable ids.
• Test an endpoint with TestClient and replace the model provider.

Further reading

• pytest: How to use fixtures and How to parametrize.
• FastAPI: Testing and Testing dependencies with overrides.
• Spring Framework: MockMvc, the Java counterpart to TestClient.

Last verified: 2026-11-02

Next

This is the last core lesson of module M1. Next is module M2, which starts with How an LLM application works.