Was Tests prüfen, bevor eine Seite erscheint

Bevor sich ipe.rest ändert, prüfen es 137 kleine Tests auf unserem eigenen Rechner. Sie brauchen etwa acht Sekunden, nur sieben davon laufen auch bei jedem Deploy, und manches können sie nicht sehen. Hier steht, worauf sie schauen.

Der gestrige Beitrag handelte von Dateien für Maschinen. Dieser handelt von etwas, dem Leserinnen und Leser nie begegnen: den Prüfungen, die laufen, bevor eine Seite online geht. Die Zahlen stammen vom 8. November 2026 und aus dem Repository, wie es vor diesem Beitrag aussah: ein Befehl, python3 -m unittest discover tests, 137 Tests, alle bestanden.

Zehn Dateien, ein Befehl

Die Tests liegen in zehn Dateien, insgesamt 1.850 Zeilen. Das meiste Gewicht liegt beim Journal: 56 der 137 betreffen seine Seiten. Weitere 23 decken die übrigen Seiten ab, etwa Über uns, Kontakt, Datenschutz und Nutzungsbedingungen, und 18 die Startseite. Der Rest sind kleine Gruppen: 9 für Benachrichtigungen an Suchmaschinen, 8 für strukturierte Daten, 7 für den Deploy, 7 für die Darstellung von Uhrzeiten, 4 für den Service Worker, 4 für Links und Asset-Versionen und 1 für das Vorschaubild.

Was sie abfangen

Viele Seiten hier werden aus unseren Quellen erzeugt: die Journalbeiträge, die Sitemap, der Feed, llms.txt und die Karten auf der Startseite. Ein Test schlägt fehl, wenn eine erzeugte Datei veraltet ist, sodass niemand eine von Hand ändern und die Quelle vergessen kann.

Andere Tests wachen über die Sprachen. Jeder Beitrag muss in allen zwölf Sprachen vorliegen, jede Seite muss auf die anderen und auf sich selbst verweisen, und die Sitemap muss dieselben Verweise enthalten wie die Seite. Wieder andere wachen über Regeln, die wir uns selbst gesetzt haben: Ein neuer Beitrag unter 300 Wörtern wird abgelehnt, einer unter 400 Wörtern bekommt nur eine Warnung, ein Beitrag mit Datum in der Zukunft wird abgewiesen, und eine Seitenbeschreibung darf nicht mit Auslassungspunkten abgeschnitten sein.

Der Service Worker, der eine Seite offline öffnen lässt, hat einen Cache-Namen mit Versionsnummer. Ein Test prüft, dass die Version in den Asset-Links jeder Seite mit der übereinstimmt, die der Service Worker aufführt, damit ein geändertes Stylesheet nicht veraltet ausgeliefert wird.

Die sieben, die bei jedem Deploy laufen

Nur eine Datei mit 7 der Tests läuft im Deploy-Workflow. Sie prüft die gebaute Seite, nicht das Repository: dass die Dateien da sind, die ein Besucher braucht, dass Ordner wie scripts und tests nicht hochgeladen werden und dass die 404-Seite auf noindex steht und zur Startseite zurückführt. Schlägt sie fehl, stoppt der Deploy, bevor etwas veröffentlicht wird.

Die übrigen 130 sind eine Gewohnheit, keine Schranke. Wir starten sie vor dem Commit, und nichts auf dem Server zwingt uns dazu.

Was sie nicht sehen

Ein bestandener Test sagt, dass die Seiten untereinander stimmig sind, nicht dass sie gut sind. Kein Test liest die zehn maschinell entworfenen Übersetzungen auf ihren Sinn hin, deshalb tragen diese Seiten einen Hinweis auf KI-Übersetzung. Kein Test hier öffnet einen Browser, daher prüfen wir das Layout auf einem schmalen Handybildschirm mit dem Auge. Und wir können nicht sagen, ob irgendein Crawler die Sorgfalt bemerkt, mit der wir diese Dateien im Gleichschritt halten.

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

Das meiste, was eine ruhige Seite ruhig hält, ist langweilig: eine Zahl, die stimmt, ein Link, der auflöst, eine Version, die weitergezählt hat. Lieber lassen wir das acht Sekunden lang eine Maschine prüfen, als zu hoffen, dass wir daran gedacht haben.