Keine Zauberei: Wie der CustomWebResolver Ihre Webanwendungs-UI testbar macht

Unser Ziel mit QF-Test ist es, das UI-Testen von Webanwendungen so einfach zu gestalten wie bei nativen Anwendungen. Dies birgt einige Herausforderungen. Unseren Lösungsansatz nennen wir den CustomWebResolver. In diesem Blogbeitrag werde ich erklären, warum QF-Test im Testen von Webanwendungen so viel besser ist als andere Tools und was dieser “CustomWebResolver” damit zu tun hat.

Das Problem mit CSS- und XPath-Selektoren

Die meisten browserbasierten UI-Testing-Tools verwenden CSS-Selektoren oder XPath, um ein Element auszuwählen, mit dem interagiert oder das validiert werden soll. Dieser Ansatz hat mehrere Nachteile:

• Sehr unhandlich: Ein typischer CSS-Selektor sieht z.B. so aus: body > main > div > ul > li:nth-of-type(3) > button.my-action, das gleiche als XPath wäre: .//body/main/div/ul/li[3]/button[@class="my-action"]. Nicht sehr lesbar.
• Nicht sehr stabil: Diese Selektoren sind darauf angewiesen, dass die zugrundeliegende HTML-Struktur der Anwendung gleich bleibt, sonst gehen sie kaputt.
• Schlecht automatisch zu generieren: Dies wird wichtig, wenn eine Interaktion aufgenommen werden soll: Irgendeinen CSS- oder XPath-Selektor für ein HTML-Element programmatisch zu generieren geht leicht. Ein stabiler, klarer und wiederverwendbarer Selektor muss jedoch normalerweise von Hand geschrieben werden.
• Kein Zugriff auf das Shadow DOM: Es ist mit CSS oder XPath nicht möglich ein Element auszuwählen, das in einem “Shadow Root” gekapselt ist. Dies ist ein Problem bei Anwendungen, die dem “Web Components”-Standard folgen. Stattdessen werden JavaScript und ein tiefes Verständnis von Webtechnologien benötig.
• Technologie-spezifisch: Diese Selektoren sind nur auf HTML anwendbar, sie können nicht in einem plattformübergreifenden Kontext verwendet werden.
• Keine Überprüfung des Zustands: Mit diesen Selektoren wird das Element erst mal nur gefunden. Die Prüfung, ob das Element den erforderlichen Zustand hat, um einen Test zu erfüllen, muss separat erfolgen.

Es gibt einen besseren Weg: Der QF-Test CustomWebResolver

Obwohl Sie auch hier mit Selektoren arbeiten können, bietet QF-Test einen besseren Weg: Eine Technologie, die wir CustomWebResolver oder kurz CWR nennen, vereinfacht das verschachtelte HTML Ihrer Anwendung zu einem semantischen Baum von wohldefinierten UI-Komponenten. Dies bringt mehrere Vorteile:

• Keine HTML-Kenntnisse erforderlich: Testautor:innen müssen die Feinheiten der DOM-Struktur der Anwendung nicht verstehen, um Komponenten anzusprechen.
• Semantische Tests: UI-Komponenten können gemäß ihrer semantischen Funktion, also wie sie sich eine:r Anwender:in darstellt, adressiert werden, anstatt auf Grundlage ihrer strukturellen Position im DOM oder im HTML-Code.
• Einheitliche Behandlung ähnlicher Komponenten: UI-Komponenten, die dieselbe semantische Funktion haben, aber auf HTML-Ebene unterschiedlich implementiert sind, werden dennoch auf dieselbe Weise angesprochen.
• Prüfungen Inklusive: Der Zustand einer UI-Komponente kann automatisch anhand gängiger Kriterien überprüft werden. Dazu zählen Dinge wie “ist sie sichtbar”, “was ist ihr Textinhalt?”, “was ist ihr Eingabewert?”, “ist sie aktiviert oder deaktiviert?”, “ist sie angehakt oder ausgewählt?” und mehr.
• Shadow DOM ist kein Problem: Mit einem CustomWebResolver müssen Sie sich nie wieder über Dinge wie “Shadow Roots” Sorgen machen – QF-Test erledigt alles nötige für Sie.
• Robust gegen DOM-Änderungen: Dank CustomWebResolver sind QF-Test Komponenten viel widerstandsfähiger gegen Änderungen an der DOM-Struktur. Und falls doch Änderungen notwendig sind, können sie an einer zentralen Stelle vorgenommen werden, anstatt in jedem Test, wo eine Komponente verwendet wird.
• Cross-Plattform: Da sie nicht an HTML gebunden ist, kann die QF-Test-Komponentenstruktur mit nur minimalen Anpassungen auch mit Java-Anwendungen, nativen Windows UIs und sogar iOS- und Android-Apps verwendet werden.
• Selektion über SmartID: In QF-Test können Sie eine Komponente über unsere extrem kompakte SmartID-Syntax z.B. in folgender Weise ansprechen: #List:&2@#Button:

Schön und gut, aber wie funktioniert diese magische CustomWebResolver-Technologie?

Die Grundlage des CustomWebResolver ist die Übersetzung der DOM-Struktur in einen Baum von Komponenten mit bestimmten generischen Klassen auf Basis einer Reihe von Zuweisungen. Lassen Sie mich diesen Satz entwirren:

Generische Klassen

Jede Benutzeroberfläche besteht aus einer Reihe von Widgets oder Komponenten, die einen bestimmten Zweck erfüllen. Normalerweise gibt es Fenster mit verschiedenen Panels, die Labels, Tabellen, Bäume, Listen, Checkboxen, Textfelder, Schieberegler, Dropdowns und so weiter enthalten können.

QF-Test wird mit einer langen Liste von generischen Klassen ausgeliefert, die verwendet werden können, um fast jede erdenkliche Komponente in einer Anwendungs-UI zu beschreiben. QF-Test versteht ihre Semantik, also wie sie funktionieren, und kann automatisch die richtigen Aktionen und Prüfungen pro Komponente anbieten.

Zum Beispiel weiß QF-Test, dass es für die generische Klasse CheckBox eine “‘checked’-Prüfung anbieten soll, aber für die generische Klasse TextField nicht. Und es versteht, dass man auf eine CheckBox-Komponente klicken kann, um ihren ‘checked’-Status umzuschalten. QF-Test versteht auch, dass eine Table oder List untergeordnete Elemente enthalten kann und ermöglicht den einfachen Zugriff auf diese.

CWR-Zuweisungen

Der CustomWebResolver hat die Aufgabe, das DOM Ihrer Anwendung zu untersuchen und herauszufinden, welche HTML-Elemente zu welcher generischen Klasse gehören. Dazu verwendet er Zuweisungen, die in der Regel in einem YAML-Dokument definiert sind. Das einfachste mögliche Mapping sieht so aus:
 

genericClasses:
- Button: btn

Dieser YAML-Block wird, wenn er vom CustomWebResolver interpretiert wird, QF-Test anweisen, jedem HTML-Element mit der CSS-Klasse btn die generische Klasse Button zuzuweisen und damit zu verstehen, dass es sich um eine Schaltfläche handelt, die geklickt werden kann, solange sie nicht deaktiviert oder unsichtbar ist.

Wenn der CustomWebResolver in dieser Weise konfiguriert wurde, können Sie jetzt “OK”-Schaltflächen mit der SmartID #Button:OK auswählen, unabhängig davon, wo sich diese Schaltfläche befindet oder welches HTML-Tag sie tatsächlich verwendet, solange sie die CSS-Klasse btn und eine Beschriftung “OK” hat.

Hier ein weiteres Beispiel für eine CustomWebResolver-Zuordnung, diesmal etwas komplexer:
 

genericClasses:
- ComboBox:
    attribute: role
    attributeValue: combobox
- List:ComboBoxList:
    tag: ul
    parent: ComboBox
- Item:ComboBoxListItem:
    tag: li
    parent: List:ComboBoxList

Die obige Zuweisung ist für eine “ComboBox”, also ein Dropdown-Eingabefeld. Sie besteht eigentlich aus mehreren Unterkomponenten:

1. Das Eingabefeld selbst (ComboBox),
2. die Liste, die erscheint, wenn das Dropdown geöffnet wird (List:ComboBoxList) und
3. die einzelnen wählbaren Optionen in der Liste (Item:ComboBoxListItem).

Dank dieser Zuweisungen kann der CustomWebResolver QF-Test anweisen, diese Art von Dropdown als eine zusammenhängende semantische Komponente zu behandeln: QF-Test kann automatisch eine bestimmte Option in der Liste auswählen, es kann die aktuelle Auswahl abrufen, es kann prüfen, ob eine bestimmte Option aktuell gewählt ist, oder es kann die gesamte Liste der verfügbaren Optionen zurückgeben – und das alles direkt über die QF-Test UI, ohne dass dafür Code geschrieben oder das DOM manipuliert werden muss.

Der Komponentenbaum

Sobald der CWR allen relevanten Komponenten eine generische Klasse zugewiesen hat, kann QF-Test den Rest des HTMLs ignorieren. Übrig bleibt eine wunderbar übersichtlicher Baum von semantischen Komponenten, auf dem Sie Ihre Tests aufbauen können.

Eine Gegenüberstellung zeigt, wie die Komplexität der DOM-Struktur einer Webanwendung reduziert wird, wenn alle DIVs und SPANs durch semantische Komponenten ersetzt werden. Die nicht optimierte Struktur auf der linken Seite ist viel tiefer Verschachtelt als die optimierte, semantische Struktur rechts.

Und wie konfiguriere ich diesen CustomWebResolver für meine Anwendung?

Das Einzige, was Nutzer:innen von QF-Test tun müssen, ist die initiale Konfiguration für den CustomWebResolver bereitzustellen. Wir haben drei Möglichkeiten implementiert, um dies so einfach wie möglich zu machen:

1. Für eine stetig wachsende Liste von Webkomponenten-Frameworks liefern wir schon CWR-Konfigurationen mit QF-Test aus. QF-Test übersetzt alle Komponenten aus diesen Frameworks automatisch in generische Klassen, die Sie dann in Ihren Tests und Prüfungen verwenden können. Wir unterstützen beliebte Frameworks wie Vaadin, Angular Material UI, und Google Web Toolkit. Schauen Sie auf die komplette Liste, um zu sehen, ob Ihr Framework bereits unterstützt wird.
2. Wenn Sie ein anderes Framework verwenden, Ihre Anwendung aber die WAI-ARIA-Standards für Barrierefreiheit einhält, indem Komponenten mit den Attributen role und aria-* gekennzeichnet werden, wird QF-Test diese Attribute zur automatischen Konfiguration des CustomWebResolver verwenden. Je besser die Zugänglichkeit Ihrer Benutzeroberfläche ist, desto besser wird auch QF-Test mit ihr arbeiten – ein doppelter Gewinn!
3. Ansonsten müssen Sie Ihre eigenen CWR-Zuweisungen schreiben. Das ist nicht besonders schwierig, aber es erfordert einige Kenntnisse der HTML-Struktur Ihrer Anwendung und der YAML-Syntax. Keine Sorge, wir unterstützen Sie dabei an allen Ecken und Enden: QF-Test bietet eine komfortable Benutzeroberfläche, die Ihnen bei jedem Schritt beim Bearbeiten und Überprüfen Ihrer Konfiguration hilft. Und mit dem QF-Test UI Inspektor können Sie die Auswirkungen Ihrer CWR-Konfiguration in Echtzeit nachverfolgen. Und wenn Sie immer noch Probleme haben, ist unser Support-Team stets bereit, Sie zu unterstützen.

Ein Screenshot des Editier-Menüs im QF-Test CustomWebResolver-Knoten. Es enthält jede Menge kontextbezogene Aktionen, die Ihnen helfen, eine gültige CWR-Konfiguration im YAML-Format zu erzeugen.

Wir sind überzeugt, dass semantische Komponenten und der CustomWebResolver der beste Weg sind, um zuverlässige, robuste und umfassende UI-Tests für Webanwendungen zu erstellen. Und unsere Kunden sehen das auch so.

Wenn Sie bereits QF-Test für Web-Tests verwenden, aber die Möglichkeiten des CustomWebResolver noch nicht voll ausgeschöpft haben, sollten Sie das einmal ausprobieren. Und wenn Sie ganz neu bei QF-Test sind, können Sie noch heute mit einer kostenlosen Testlizenz loslegen!

Zum Weiterlesen

• Der CustomWebResolver im QF-Test Handbuch: Verbesserte Komponentenerkennung mittels CustomWebResolver
• Tutorial zur Konfiguration Ihres ersten CustomWebResolver: Beispiel für den “CarConfigurator Web”
• Liste der Frameworks mit mitgeliefertem CWR: Besondere Unterstützung für verschiedene Web-Komponentenbibliotheken
• Detaillierte Dokumentation aller Möglichkeiten des CWR: Der CustomWebResolver installieren Knoten