What the tests check before a page ships

Before ipe.rest changes, 137 small tests check it on our own machine. They take about eight seconds, only seven of them also run on every deploy, and there are things none of them can see. Here is what they look at.

Yesterday’s entry was about files for machines. This one is about something readers never meet: the checks that run before a page goes live. The figures are from 8 November 2026, taken from the repository as it stood before this entry was added: one command, python3 -m unittest discover tests, 137 tests, all passing.

Ten files, one command

The tests live in ten files, 1,850 lines in all. Most of the weight is on the journal: 56 of the 137 are about journal pages. Another 23 cover the other pages, such as about, contact, privacy and terms, and 18 cover the home page. The rest are small groups: 9 for search-engine notifications, 8 for structured data, 7 for the deploy, 7 for how times are shown, 4 for the service worker, 4 for links and asset versions, and 1 for the share image.

What they catch

Many pages here are generated from our sources: the journal entries, the sitemap, the feed, llms.txt and the cards on the home page. A test fails if any generated file is out of date, so nobody can edit one by hand and forget the source.

Other tests guard the languages. Every entry must have a version in each of the twelve languages, each page must link to the others and to itself, and the sitemap must list the same links the page does. Others guard the rules we set ourselves: a new entry under 300 words is refused, one under 400 words only gets a warning, an entry dated in the future is turned away, and a page description may not be cut off with an ellipsis.

The service worker, which lets a page open offline, has a cache name that carries a version number. A test checks that the version in each page’s asset links matches the one the service worker lists, so a changed stylesheet is not served stale.

The seven that run on every deploy

Only one file, with 7 of the tests, runs in the deploy workflow. It checks the built site rather than the repository: that the files a visitor needs are there, that folders such as scripts and tests are not uploaded, and that the 404 page is marked noindex and links home. If it fails, the deploy stops before anything is published.

The other 130 are a habit, not a gate. We run them before we commit, and nothing on the server makes us.

What they cannot see

A passing test says the pages agree with each other, not that they are good. No test reads the ten machine-drafted translations for meaning, which is why those pages carry an AI-translation note. No test here opens a browser, so layout on a narrow phone screen is checked by eye. And we cannot say whether any crawler notices the care we take in keeping these files in step.

ipe(); // check the plain things, every time

Most of what keeps a quiet site quiet is dull: a count that matches, a link that resolves, a version that moved. We would rather a machine check that for eight seconds than hope we remembered.