KENSAI Produktaktualisierung: Nächtliche Testnachweise ersetzen beschönigende Kennzahlen

Der 26. April begann mit jener Art von Fehler, die nützliche Systeme bewahren sollten, statt sie zu beschönigen: Die nächtliche Freemium-Testsuite wurde nicht erfolgreich abgeschlossen. Der Fortschritt besteht darin, dass der Fehler jetzt präzise genug ist, um ihn zu beheben.

Was der nächtliche Testlauf bewiesen hat

Der Cron-Beleg vom 26. April erfasste die vollständige KENSAI Freemium-Testsuite aus dem Plattform-Repository. Das Ergebnis war kein unspezifischer fehlgeschlagener Build. Es war eine konkrete Fehlerübersicht: pnpm test wurde nach 636 Tests mit Exit-Code 1 beendet; 310 Tests schlugen fehl, 243 waren erfolgreich und 83 wurden übersprungen.

Die vorherrschende Fehlerklasse bestand aus API-gestützten Tests, die einen Dienst unter 127.0.0.1:4000 erwarteten, während die API nicht verfügbar war. Dies führte zu abgelehnten Verbindungen und Prüfungen mit Status null. Das ist kein unerklärliches Produkträtsel, sondern ein Defekt durch eine fehlende Vorabprüfung und Dienstorchestrierung.

Was fehlte

Zwei weitere Lücken wurden erfasst, statt verborgen zu werden. Das Root-Paket definierte kein pnpm test:e2e, sodass der Testrunner keinen stabilen e2e-Einstiegspunkt hatte. Der Befehl zur Ermittlung der Testabdeckung schlug sofort fehl, weil @vitest/coverage-v8 fehlte. Ein direkter Playwright-Fallback startete zwar, doch umfangreiche Authentifizierungs- und Admin-Fehler sowie einminütige Validierungs-Timeouts erzeugten so viel Rauschen, dass der Lauf abgebrochen wurde, anstatt ihn fälschlicherweise als nützliches Signal zu interpretieren.

Warum dies eine Produktaktualisierung ist

Ein fehlgeschlagener Testlauf ist nicht automatisch ein Fortschritt. Ein fehlgeschlagener Testlauf mit Zahlen, vorherrschenden Fehlerklassen, fehlenden Werkzeugen und dem nächsten Reparaturpfad ist Fortschritt. Das Qualitätssystem kennt jetzt den Unterschied zwischen fehlerhaftem Anwendungsverhalten und Infrastruktur, die nie gestartet wurde.

Das ist für KENSAI wichtig, weil kundenorientierte Sicherheitsaussagen von nüchterner betrieblicher Wahrheit abhängen. Wenn der Freemium-Pfad die API benötigt, muss der Testrunner sie starten oder ihre Verfügbarkeit vor Testbeginn überprüfen. Wenn die Testabdeckung ein erforderliches Prüfkriterium ist, muss der Anbieter installiert sein. Wenn e2e zur Release-Strategie gehört, braucht es ein echtes Skript statt einer nur vorausgesetzten Konvention.

Nächster Reparaturpfad

Die Reparaturreihenfolge ist jetzt klar: ein Root-Skript namens test:e2e hinzufügen oder wiederherstellen, den Anbieter für die Testabdeckung installieren und dafür sorgen, dass der Freemium-Testrunner die API auf Port 4000 startet und ihren Zustand überprüft, bevor API-abhängige Tests ausgeführt werden. Alles andere wäre Theater.

Diesen Standard sollte KENSAI beibehalten: die unbequeme Messung bewahren, die fehlerhaften Voraussetzungen benennen und aus einem roten Testlauf eine kurze Liste konkreter Korrekturen machen.

Fazit

Der sinnvolle Standard ist einfach: Aussagen werden real, wenn Voraussetzung, Artefakt und Route übereinstimmen. Die heutige Arbeit sorgt dafür, dass dieser Standard sichtbar bleibt.