8. Mini-project: fake green, real red

Description

This is the module's practical close. The previous seven lessons gave you the "why" piece by piece —the difference between unit and integration, the pyramid, the seams, the problem of the deceptive green, the types of integration and their cost—. Now it's your turn to weave it all into a single deliverable that demonstrates the guide's central thesis with your own hands: a unit test with the FakeBookingRepository passes green, while the integration test with the real SqliteBookingRepository fails red because of the seam's divergence. It's not a new tool; it's the whole module condensed into two tests and a diagnosis.

What is really evaluated here isn't that you get the red —that's easy— but that you can explain why the green was lying. Anyone can paste two tests and see that one fails. The deliverable that matters is the diagnosis: naming the seam where the two providers diverge, pointing out the exact field that changes shape when crossing it, explaining why the fake couldn't catch the bug (because the fake is the assumption that turned out false), and locating where the solution lives in the rest of the guide. A student who turns in the red without the diagnosis hasn't demonstrated they understood the module; one who turns in the complete diagnosis has demonstrated they'll never again read a green suite of pure unit tests without asking which seams were left unverified.

Connection to the module: this lesson is module 1's practical exam and its close. It gathers the gap lesson 1 showed you, lesson 2's definition, lesson 4's seam, lesson 5's mechanism of deception, and lesson 7's cost criterion, and presents them as a project with deliverables and a reference solution. After the statement, it summarizes the module and points you to module 2, where we'll see another divergence of the same seam —the fake that returns None where the real one raises— to begin building, starting in module 3, the systematic solution: the contract.

Analogy: the inspector's report

Think of a building inspector who finds a poorly calculated joint —the one from lesson 1's example, the beam that doesn't rest well on the column—. Their job doesn't end when they see the crack; it ends when they turn in the report: where the joint is, which two pieces it connects, why it gives (the short bolt, the steel that expands differently), why the piece-by-piece review didn't detect it (each piece met its standard separately), and whose job it is to fix it. An inspector who only says "something looks wrong" is useless; one who turns in the complete report allows the right thing to be fixed, in the right place, for the right reason.

Your mini-project is that report. The integration test's red is the crack you found; the deliverable is the report that explains it. You'll document where the seam is, which two providers diverge at it, which field gives when crossing it, why the green unit tests didn't detect it, and where —in which modules of the guide— the fix lives. Turning in the report, not just the crack, is what separates "I saw it fail" from "I understand why it fails and what to do about it".

The project: formal statement

Your task is to demonstrate, from start to finish and with real pytest output, that a green unit test can hide a broken integration in Reservo. Specifically:

Write two tests of the same business behavior —book Focus for 3 h for the pro member Ana and verify that the booking was saved correctly (with price_cents == 6000 and the start that was booked)—:

• The unit test uses the FakeBookingRepository (and a payment stub, an email spy, a fixed clock). It must pass green.
• The integration test uses the real SqliteBookingRepository (same payment, email, and clock doubled; only the repository changes). It must fail red, on the start assertion.

Deliverables

1. The two tests, in a single file, identical except for the repository they receive. The only difference between them must be the piece plugged into the repo seam; everything else —the data, the assertions— the same.
2. The real pytest output from running the file with -v, showing the unit test as PASSED and the integration one as FAILED, with the AssertionError block that gives away the start's type.
3. The diagnosis (the deliverable that weighs most), answering four questions: (a) at which seam do the two providers diverge? (b) which field changes shape when crossing it, and to what type? (c) why couldn't the unit test with the fake catch this bug? (d) where, in the rest of the guide, does the solution live?
4. The assertion that does survive. Point out the assertion that passes in both tests (price_cents == 6000) and explain why that field crosses the seam without trouble while the start doesn't.

Worked example: the two tests and their output

Here is the complete file: two twin tests, one with the fake, one with the real. Read them and notice that the only real difference is the repository line —FakeBookingRepository() versus SqliteBookingRepository(sqlite3.connect(":memory:"))—; the rest, including the two final assertions, is identical.

# tests/test_book_persists_correctly.py — the same book, two different repos
import sqlite3
from datetime import datetime

from reservo.calendar import Calendar
from reservo.doubles import (FakeBookingRepository, FixedClock,
                             SpyEmailSender, StubPaymentGateway)
from reservo.models import Member, Room
from reservo.services import BookingService
from reservo.sqlite_repo import SqliteBookingRepository

FOCUS = Room(id="focus", name="Focus", capacity=4, hourly_cents=2500)
ANA = Member(id="m-ana", name="Ana", tier="pro")
START = datetime(2026, 3, 10, 9)
END = datetime(2026, 3, 10, 12)          # Focus 3 h
CLOCK = datetime(2026, 3, 1, 9)


def make_service(repo):
    return BookingService(
        Calendar(), FixedClock(CLOCK),
        StubPaymentGateway(ok=True), SpyEmailSender(), repo,
    )


# --- unit: the repository is an in-memory double ---
def test_book_persists_the_booking_with_fake_repo():
    repo = FakeBookingRepository()
    service = make_service(repo)

    booking = service.book(FOCUS, ANA, START, END)

    saved = repo.get(booking.id)
    assert saved.price_cents == 6000     # the correct charge
    assert saved.start == START          # the booking was stored intact


# --- integration: the repository is real SQLite ---
def test_book_persists_the_booking_with_sqlite_repo():
    repo = SqliteBookingRepository(sqlite3.connect(":memory:"))
    service = make_service(repo)

    booking = service.book(FOCUS, ANA, START, END)

    saved = repo.get(booking.id)
    assert saved.price_cents == 6000     # the correct charge
    assert saved.start == START          # <-- here the two repos diverge

What to expect. On my machine (Python 3.14.0, pytest 9.1.1):

python3 -m pytest tests/test_book_persists_correctly.py -v

============================= test session starts ==============================
platform darwin -- Python 3.14.0, pytest-9.1.1, pluggy-1.6.0
collected 2 items

tests/test_book_persists_correctly.py::test_book_persists_the_booking_with_fake_repo PASSED [ 50%]
tests/test_book_persists_correctly.py::test_book_persists_the_booking_with_sqlite_repo FAILED [100%]

=================================== FAILURES ===================================
_______________ test_book_persists_the_booking_with_sqlite_repo ________________

    def test_book_persists_the_booking_with_sqlite_repo():
        repo = SqliteBookingRepository(sqlite3.connect(":memory:"))
        service = make_service(repo)

        booking = service.book(FOCUS, ANA, START, END)

        saved = repo.get(booking.id)
        assert saved.price_cents == 6000     # the correct charge
>       assert saved.start == START          # <-- here the two repos diverge
E       AssertionError: assert '2026-03-10T09:00:00' == datetime.datetime(2026, 3, 10, 9, 0)
E        +  where '2026-03-10T09:00:00' = Booking(id='bk-1', ..., start='2026-03-10T09:00:00', ...).start

tests/test_book_persists_correctly.py:50: AssertionError
========================= 1 failed, 1 passed in 0.02s ==========================

There's the complete demonstration: 1 failed, 1 passed. The same book, the same assertion, two verdicts —green with the fake, red with the real—, and the red pointing to the exact line and the exact type: '2026-03-10T09:00:00' (a str) versus datetime.datetime(2026, 3, 10, 9, 0). With this you have deliverables 1 and 2. What's missing is the one that weighs: the diagnosis.

Reference solution

Common mistakes

Turning in the red without the diagnosis. What happens: someone pastes the two tests, shows the 1 failed, 1 passed, and considers the project done. Why it happens: the red "feels" like the deliverable, because it's the visible part. How to detect it: if you can't answer the diagnosis's four questions —seam, field, why the fake didn't see it, where the fix lives—, you're missing the central deliverable. How to fix it: the mini-project evaluates the understanding, not the red; the red is the evidence, the diagnosis is the thesis. Write the inspector's report, not just the photo of the crack.

Making the two tests differ in more than the repository. What happens: someone, unintentionally, uses different data or different assertions in the unit and integration tests, and the contrast stops being clean. Why it happens: they're written separately and a difference slips in. How to detect it: if comparing the two tests there's more than one different line (the repository one), the experiment isn't controlled —you can't attribute the red only to the seam—. How to fix it: extract everything common to a helper (make_service(repo)) and to shared constants (START, END), so that the two tests are identical except for the plugged-in piece. An experiment with a single variable is the one that proves something.

Concluding "fakes are bad, they should be deleted". What happens: someone, impressed by the red, decides the problem is the fakes and that everything should be tested against SQLite. Why it happens: if the fake hid the bug, the fake seems the culprit. How to detect it: if your conclusion is "away with the doubles", it contradicts the pyramid (lesson 3) and the cost (lesson 7). How to fix it: the fake isn't the culprit; the illegitimate conclusion we drew from its green is. The fake is still your speed and your precision at the base of the pyramid; what was missing was the integration test that covers the seam and —starting in module 3— the contract that keeps the fake honest. The answer isn't fewer doubles: it's doubles plus integration plus contract, each in its place.

Exercises

Exercise 1 — Predict another divergence of the same seam. Without running anything, design a third test that exposes a divergence different from the datetime between the fake and the real, using the booking's end. Predict what the fake will do and what SQLite will do, and on which assertion the integration one would fail.

def test_book_persists_end_with_sqlite_repo():
    repo = SqliteBookingRepository(sqlite3.connect(":memory:"))
    service = make_service(repo)
    booking = service.book(FOCUS, ANA, START, END)
    saved = repo.get(booking.id)
    assert saved.end == END              # END = datetime(2026, 3, 10, 12)

Exercise 2 — The fix, and why we don't do it yet. The diagnosis says the datetime fix lives in SqliteBookingRepository.get, converting the text back with datetime.fromisoformat(...). Write how the line would look, and explain why in module 1 we do not apply it and leave the red.

from datetime import datetime
# ...
    return Booking(
        id=row[0], room_id=row[1], member_id=row[2],
        start=datetime.fromisoformat(row[3]),   # text -> datetime back
        end=datetime.fromisoformat(row[4]),
        status=row[5], price_cents=row[6],
    )

Exercise 3 — Explain it to your team. A colleague, seeing your mini-project, says: "but our 400 unit tests are all green, this is a contrived case". Write the three-sentence answer you'd give them, leaning on what you demonstrated.

Summary and module close

With this mini-project turned in, you close module 1. You demonstrated with your own hands the thesis that holds up the guide: the same Reservo book passes green with the FakeBookingRepository and fails red with the real SqliteBookingRepository, and you were able to explain why —the repository seam, the datetime that serializes to text and comes back as a str, the fake that couldn't catch the bug because it embodied the false premise, and the integer price_cents that does survive because it has a native type in the database—. You turned in the inspector's report, not just the photo of the crack.

You went through the whole module: the gap between doubling and testing the real thing (lesson 1); the precise definitions of unit and integration (lesson 2); the pyramid that dictates the proportion (lesson 3); the seams where integration lives (lesson 4); the mechanism of deception of the green that hides a red (lesson 5); the types of integration to name what you're testing (lesson 6); and the cost that gives everything its shape (lesson 7). You come out knowing why integration exists, with the reflex of looking at any green suite and asking which seams were left unverified against the world.

Where the guide goes next. Module 1 was the diagnosis; now the treatment begins. Module 2 takes another divergence of this same seam —the fake that returns None where the real SqliteBookingRepository raises— and shows how that bug passes the unit test and blows up in production, sharpening the problem until it's ready for its solution. Starting in module 3, that solution arrives: the consumer-driven contract, a battery of behavior you run against the fake and against the real, so that no divergence can hide behind a green again. From there on (modules 5 to 7) you'll take integration to the real resources —SQLite, files, HTTP— with its cost well managed. The gap you only saw today, you're going to close.

Resources

• pytest documentation — How to invoke pytest (-v, selecting tests) — the reference for running the file with -v and producing your own "What to expect" block with the PASSED/FAILED, as in the worked example.
• sqlite3 — Adapter and converter recipes (Python documentation) — the section that explains the serialization that causes the divergence and how (in the right module) the conversion back to datetime is registered; the foundation of deliverable 3(d) and exercise 2.
• datetime.fromisoformat — Python documentation — the function that reconstructs a datetime from the ISO text SQLite returns; the provider fix that exercise 2 writes but the module leaves for later.
• test-doubles-and-test-data-guide — the sister guide where the FakeBookingRepository was born; useful to remember that a fake is an implementation you write, and therefore a premise of yours about the real thing —exactly the premise this mini-project put to the test—.