The safety net

Tests, in tiers

The system has a substantial test suite, organised in tiers by what each one actually needs to run.

Unit tests cover the pieces that are pure logic — the typography normaliser, the reading-time calculation, the social-image rules, the content readers.

API tests drive the editing application’s own interfaces against a throwaway content directory. Create a book, add chapters, reorder them, delete one, confirm the numbering closed the gap.

Interface tests drive the editing application in a real browser, with real mouse clicks at real screen positions.

That last one exists because of a specific failure. A tab was built, verified by calling its show-function from a console, and shipped — and a stylesheet rule hid the tab itself above a certain screen width. There was no way to reach it by clicking. “The panel renders” and “a person can get to the panel” are different claims, and only the second one matters. So every interaction in that tier goes through a real click at a real coordinate; if a control is covered, collapsed or off-screen, the click lands on whatever is actually there and the test fails.

End-to-end tests run the real front end in a real browser and check the things that only exist once something is rendered: that no page scrolls sideways at any of a dozen device sizes in either theme, that every image decodes, that the sitemap contains what it should, that the deck viewer steps correctly and that full screen fits a slide to the display.

Live tests run against the published site, for the claims that can only be made there — content protection, which is production-only by design, and the metadata search engines actually read.

Assertions that have been proven to fail

A discipline worth naming: an assertion is only trusted here once it has been watched to fail. Break the behaviour deliberately, confirm the test catches it, put the behaviour back.

That has caught tests that asserted nothing. One claimed a particular file operation would clobber a chapter; sabotaging the code to do the dangerous thing changed nothing, because the danger did not exist. The test had been describing a hazard that was not real, and it would have gone on passing forever.

The Monitor

A tab that watches the live site rather than the code.

It checks that pages answer, that the metadata is intact, that no draft is reachable, and it keeps a history so a change in behaviour is visible as a change rather than as a single reading.

The distinction from tests is worth being clear about: tests check the code is correct. The Monitor checks the site is up and correct right now, which is a different question with different failure modes — an expired certificate, a platform incident, a deploy that half-succeeded.

Backups

The content is in version control, which is already a strong position. Backups cover what version control does not: the case where the repository itself is lost, and the case where something was deleted and committed without anyone noticing for a month.

Archives run on a schedule and on demand, and they are encrypted at rest.

There is also a trash. Deleting an article, a book or a deck moves it rather than unlinking it. A mis-click has to be recoverable, and “are you sure?” is not a recovery mechanism — it is a speed bump that people learn to click through.