Papyrus Online works — or so it seems when you try it by hand. But "I tried it by hand on Tuesday" is not verification: it is an anecdote. This lesson turns the 12-01 acceptance criteria into an executable test suite, the one that lets you touch any piece of the system and know in twenty seconds whether you broke something. We will apply the M9 pyramid to the complete project — what gets tested at each level and with which tool —, write the integration test that walks the whole flow (sell → persist → reload → reconcile the till), test the interface with its test client, and learn to debug across the layers when a test says no. At the end: the quality checklist that decides whether the project is ready to ship.

1. The pyramid applied to Papyrus Online
2. Test data vs real data: the canonical fixtures
3. The minimum required suite (criteria → tests)
4. The full-flow integration test
5. Testing the interface: Flask's test client / Django's Client
6. Regressions: every bug leaves its test
7. Debugging the integrated system
8. Final quality checklist

In 09-01 the pyramid was theory; now it has names attached. Each level tests a different thing, with a different tool, and in the right proportion (many at the bottom, few at the top):

The distribution rule: if a behavior can be tested at a lower level, it is tested there. The 12.35 rounding is verified at the unit level, not by firing HTTP requests; the endpoint only verifies that it translates correctly (right JSON, right code), because the substance is already tested further down. Testing the rounding over HTTP works, but it is slow, brittle and, when it fails, it doesn't tell you where the bug is.

An absolute rule: tests never touch data/. A test that writes to your real catalog is a bomb: it corrupts your data or, worse, passes or fails depending on what you sold yesterday. All tests work over tmp_path (M9) with the canonical fixtures — the four books of always, precisely because you have known their numbers by heart for eleven modules:

Here the 12-02 design decision pays off: because the service receives the repositories already built, the tests inject tmp_path repositories without touching a line of production code. If your service had opened "data/catalog.json" directly, this lesson would be impossible. Code that is easy to test and code that is well designed are the same code.

The 12-01 acceptance criteria, one by one, turned into named tests. This table is your NFR1: the suite is complete when every row exists and passes:

With the parametrizations, that adds up to about 25 tests. It is not a magic number: it is the literal translation of the 12-01 contract. If tomorrow you add a requirement, its row appears here before its code — that was TDD (09-03), and this project is the best place to practice it.

The most valuable test in the project: it walks the four data layers (service → disk → reload → aggregate) and checks that the whole story adds up. Complete and commented:

The detail that makes it a true integration test is in step 2: the new instance. If you reuse the original service, the test can pass even with a broken save(), because the object remembers the stock in memory. Reloading from disk is what proves FR4.

Track A — Flask's test client (10-03). To inject the tmp_path you will need the app factory pattern: a create_app(service) function instead of wiring up a global service at import time. It is a ten-minute refactor that proves the rule once more: testing improves the design.

Track B — Django's Client (10-05), where TestCase gives you a clean database per test (its equivalent of tmp_path):

Notice what these tests verify: the translation, not the business. That the 409 is a 409, that the JSON carries the amount, that the form re-shows the error. The 18.67 calculation was already proven two levels further down.

During 12-03 you found bugs (we all do). The 09-05 rule, now as project discipline: no bug is closed without its test. The flow: bug detected → you write the test that reproduces it (it fails, red) → you fix → the test passes (green) → the test stays in the suite forever. That test is worth more than ten invented ones: it guards a spot where your system proved it knew how to break. Note every regression in DECISIONS.md with one line ("close_till was adding strings — test_close_till_converts_amounts"): in 12-05, that list will be gold for your retrospective.

When a test (or real use) fails in the complete system, the bug can be in any of the four layers. Three techniques, in order:

• Read the traceback ACROSS the layers. A traceback from the integrated system is long: Flask/Django lines, your lines in app.py, in services.py, in repositories.py. Walk it bottom-up and locate the last line that is yours: that is the layer where it blew up. But careful: where it blows up is not always where it broke — a KeyError in the service can be a JSON badly saved by the repository three sales ago. The traceback gives you the layer of the explosion; the cause may live one layer further down.
• The log as a witness between layers. papyrus.log records what each layer did and in what order (FR7 is no longer a bureaucratic requirement: it is your black box). The endpoint returned a 500? Check the log: if the last line is a sale's INFO, the failure came after selling — in the save or in serializing the response. You just ruled out two layers without opening the debugger.
• pdb at the integration point. breakpoint() right where one layer hands over to the next (the endpoint's call to the service, the service's call to the repository) and inspect the package crossing the border: p payload, p type(row["units"]). As 12-03 said: most integration bugs are "I thought you were passing me X and it was Y" — and the border is where you see it.

Before declaring the project "shippable", run it through this list. It is not bureaucracy: it is the difference between believing it is right and knowing it.

• [ ] FR1: duplicate creation rejected; delete + lookup → not found. Test green.
• [ ] FR2: the 8 canonical amounts exact (parametrized); fake member rejected.
• [ ] FR3: a sale without stock changes nothing (check the stock after the error!); 18.67 with member+coupon; fake coupon rejected.
• [ ] FR4: the integration test passes; killing the process mid-save does not corrupt the JSON.
• [ ] FR5: every route/view with its status-code test.
• [ ] FR6: report over sales_2026.csv → 520 units, Saturday 130, PNG generated.
• [ ] FR7: caplog (or the file) confirms the WARNING on every rejection.
• [ ] NFR1: pytest → all green, ~25 tests, none touching the real data/.
• [ ] NFR2: zero public package functions without type hints.
• [ ] NFR3: zero generic except Exception without a written justification.
• [ ] NFR4: the README exists and someone else could start the project with it (verified in 12-05).

• Testing the business over HTTP. If test_api_... verifies roundings, you have the pyramid upside down: slow, brittle and with poor diagnostics. The endpoint tests the translation; the domain tests the substance.
• Tests that share state. The classic symptom: they pass alone, they fail in the suite (or depending on the order). Cause: they write to the same place. The data_dir fixture creates a fresh world per test; always use it.
• Comparing floats recklessly. assert amount == 18.67 works here because we round to 2 decimals at a single point (12-03). If an amount assert fails by 0.0000001, don't "fix the test with pytest.approx": you have one rounding too many or too few in the code. approx is for continuous mathematics, not for rounded money.
• Deleting the test of a fixed bug ("it doesn't fail anymore, it's redundant"). It is exactly the other way around: it is the only test with a proven real failure in its history.
• Debugging by sprinkling print everywhere. You already have three better, ordered tools: traceback (which layer?), log (what happened before?), pdb (what crosses the border?). Stray prints end up forgotten in the code — the log is a print with a contract.

1. Project milestone — the complete suite. Implement the 12 rows of the minimum suite (with their parametrizations). Verification: pytest -v all green, and each test's name says which FR it covers without opening the file.
2. Project milestone — the atomic-save test. Write test_save_is_atomic: trigger a failure midway through save (hint: pass a catalog containing a non-serializable object, which will make json.dump blow up) and check that the original file remains intact and loadable. This test justifies the whole os.replace design from 12-03.
3. Project milestone — your regression. Pick the most painful bug you found in 12-03, write its regression test with a name that tells the story, and add the matching line to DECISIONS.md.

1. A self-check instead of a solution: run pytest --collect-only and compare the list with the minimum-suite table; each row must have at least one collected test. If test_report_... takes a few seconds, that is fine: it is the price of pandas + PNG, and that is why there is one, not twenty.
2. Reference: broken_catalog = dict(catalog); broken_catalog["X"] = object() and with pytest.raises(TypeError): repo.save(broken_catalog); afterwards, repo.load() must return the original catalog without error. If your save was writing directly onto self._path, this test will tell you so with a JSONDecodeError — and you have just understood, through a controlled failure, what the temporary file existed for.
3. No single solution. Quality criterion for the name: someone who never lived the bug must understand what it guards — test_close_till_converts_amounts_to_float yes; test_fixed_bug_2 no.

Papyrus Online is no longer code that seems to work: it is a verified system. The pyramid stopped being a drawing — a domain with millisecond unit tests, a service over tmp_path, an integration test that walks sell → persist → reload → reconcile, and an interface whose HTTP translation is proven with its test client. The 12-01 criteria are now 25 named tests, every development bug left its regression behind, and you know how to debug across the layers with the traceback, the log and pdb at the borders. The final checklist is ticked: the project is finished. But finished is not the same as delivered: someone else still needs to be able to install it, understand it and see it work — and you still need to be able to tell its story. Documentation, a demo, the final report and a look back over the whole road: that is the last lesson of the course.