Der 'CustomWebResolver installieren' Knoten

Die Zuordnung der funktionalen HTML-Elemente zu Generische Klassen erfolgt im Normalfall über den 'CustomWebResolver installieren' Knoten.

7.0+ Vor QF-Test Version 7 erfolgte diese Zuordnung über die Prozedur installCustomWebResolver und updateCustomWebResolverProperties aus der Standardbibliothek qfs.qft. Diese Prozeduraufrufe sollten nun in 'CustomWebResolver installieren' Knoten konvertiert werden. Vor der Konvertierung des Prozeduraufrufs wird eine automatische Prüfung der enthaltenen Parameter durchgeführt, um mögliche fehlerhafte Angaben aufzudecken und den Wechsel auf den 'CustomWebResolver installieren' Knoten zu vereinfachen. Falls Ihr Prozeduraufruf Variablen enthält, müssen Sie bei der Konvertierung ein Testlaufprotokoll angeben, in dem die gewünschten Variablenwerte ersichtlich sind. Falls Ihr Prozeduraufruf ungültige Einträge als Kommentar verwendet, müssen Sie diese möglicherweise vor der Konvertierung entfernen oder nach der Konvertierung an die gewünschte Stelle verschieben.

Wenn Sie zur Erstellung der Verbindungssequenz den Schnellstart-Assistenten, siehe Kapitel 3, verwendet haben, was wir sehr empfehlen, finden Sie den 'CustomWebResolver installieren' Knoten im letzten Knoten der Startsequenz. Diesen Knoten sollten Sie bei Bedarf für Ihre Anwendung konfigurieren.

WebResolver_setup_sequence
Abbildung 49.2:  Aufruf des CustomWebResolvers im 'Vorbereitung' Knoten des Schnellstart-Assistenten

Allgemeine Informationen zur Web-Komponentenerkennung finden Sie in Erkennung von Web-Komponenten und Toolkits sowie in Generelle Konfigurationsmöglichkeiten.

Nachfolgend wird zunächst die Syntax des 'CustomWebResolver installieren' Knotens und anschließend die Konfigurationskategorien erläutert.

Hinweis Bitte beachten Sie, dass Änderungen im 'CustomWebResolver installieren' Knoten die Erkennungsmerkmale für ein GUI-Element verändern können. Infolgedessen können sie von den Wiedererkennungsmerkmalen bereits aufgenommener 'Komponente' Knoten abweichen. Änderungen sollten daher in bereits vorhandenen 'Komponente' Knoten, wie in 'Komponenten' aktualisieren beschrieben, nachgezogen werden. Im Idealfall sollte die Konfiguration des 'CustomWebResolver installieren' Knotens vor der Erstellung der Tests erfolgen und Knoten, die während der Konfigurationsphase erstellt wurden, wieder gelöscht werden.

'CustomWebResolver installieren' Knoten – Syntax

Die Konfiguration des 'CustomWebResolver installieren' Knotens findet in dessen Editorfeld unter Verwendung der YAML-Syntax statt. Dabei sind nur Grundkenntnisse über die Funktionsweise von YAML notwendig, welche nachfolgend erläutert werden.

Auf oberster Ebene existieren die Kategorien (siehe folgende Abschnitte). Diese stehen in einer eigenen Zeile und werden mit einem Doppelpunkt abgeschlossen (Dictionary-Schlüssel). Auf der zweiten Ebene gibt es Einträge, die jeweils in einer neuen Zeile mit einem Bindestrich beginnen (Listen-Elemente). Weitere Ebenen sind durch Einrückung gekennzeichnet.

Um die Arbeit mit der YAML-Konfiguration zu erleichtern, können über die Werkzeugleiste über dem Editor verschiedene Vorlagen eingefügt werden.

CWR Standardeinträge
Abbildung 49.3:  'CustomWebResolver' Konfigurationsvorlagen

Das Auswahlmenü, das über den Editier-Button Vorlagen einfügen neben der Zeilennummerierung geöffnet wird, ist kontextsensitiv. Es bietet für die jeweilige Zeile alle passenden Aktionen an. Wenn Sie über das Auswahlmenü arbeiten, haben Sie immer die volle Übersicht über die möglichen Aktionen und bekommen automatisch die korrekte Syntax vorgelegt.

Wenn Sie Schnellstart Ihrer Anwendung zur Erstellung der Verbindungssequenz verwendet und dort die Standardeinstellung bei der Framework-Auswahl belassen haben, erhalten Sie eine Konfiguration mit zwei Kategorien und zwei Einträgen auf der zweiten Ebene plus einige erläuternde Kommentare:

CWR Eintrag 1
Abbildung 49.4:  'CustomWebResolver' mit Vorlage für genericClasses

In dieser Konfiguration wurde die Zeile nach der Kategorie genericClasses angeklickt und anschließend über den Editier-Button Vorlagen einfügen links neben der Zeilennummerierung eine Vorlage für eine generische Klasse eingefügt. (Die Kommentare wurden entfernt.)

CWR Eintrag 1
Abbildung 49.5:  'CustomWebResolver' mit zwei generischen Klassen

Anschließend wurde die generische Klasse List eingetragen sowie die CSS-Klasse datalist. HTML-Elementen mit dieser CSS-Klasse wird bei der Komponentenerkennung nun diese generische Klasse zugewiesen. Der Vorgang wurde für die generische Klasse Item:ListItem wiederholt. Diese wird jedem GUI-Element mit dem Tag LI zugewiesen. Im Normalfall gibt es jedoch auch HTML-Elemente mit diesem Tag, die eine andere Funktion haben. Hier sollen nur solche LI-Elemente berücksichtigt werden, die sich in einer List-Komponente befinden. Daher wird im nächsten Schritt über den Editier-Button Editier-Button der Eintrag "Ancestor hinzufügen" ausgewählt. Sie sehen, dass sich die Syntax für den Eintrag ändert: sobald mehr als ein Merkmal für die Zuweisung benötigt wird, wird die erste Zuweisung mit einem passenden Präfix in die nächste Ebene verschoben und das weitere Merkmal auf dieser Ebene hinzugefügt.

Konfigurationsvorlagen
Abbildung 49.6:  'CustomWebResolver' mit komplexerer Zuweisung
'CustomWebResolver' Konfigurationskategorien

Jeder 'CustomWebResolver' basiert unter anderem auf einer global definierten Standardkonfiguration mit allgemeingültigen Regeln, die Sie in der mitgelieferten Bibliothek qftest-7.1.1/include/qfs-resolvers.qft in der Prozedur qfs.web.cwr.helpers.default einsehen können.

Eine vollständige Liste aller verfügbaren Konfigurationskategorien finden Sie in QF-Test im Knoten 'CustomWebResolver installieren' über die Schaltfläche "Neue Zuweisung".

In den folgenden Abschnitten werden die wichtigsten Konfigurationskategorien kurz erklärt. Bitte beachten Sie, dass Sie sämtliche Funktionen der verschiedenen Kategorien über den kontextsensitiven Editier-Button Editier-Button erreichen können. Nicht jede mögliche Variation der Syntax wird hier beschrieben.

Konfigurationskategorie base

Enthält den Kurznamen des Basis-Resolvers, der als Grundlage der Konfiguration verwendet werden soll:

  • autodetect: automatische Erkennung des verwendeten Frameworks. Fällt auf custom zurück, falls kein unterstütztes Framework erkannt wurde.
  • custom: die Anwendung wurde mit keinem der von QF-Test unterstützten Frameworks erstellt. In diesem Fall kann base auch komplett weggelassen werden.
  • Der Kurzname des Frameworks, zum Beispiel vaadin:
    Es werden die mit QF-Test in qftest-7.1.1/include/qfs-resolvers.qft ausgelieferten Zuweisungen für das entsprechende Framework verwendet. In Ihrer Konfiguration können Sie diese mit eigenen Zuweisungen ergänzen.

    Den Kurznamen des jeweiligen Frameworks können Sie der Tabelle Tabelle 49.7 entnehmen. Wenn Sie die Startsequenz über den Schnellstartassistenen erstellen lassen und dort ein Framework angeben, wird der Kurzname direkt hier eingetragen.

    Als Kurzname kann hier auch der volle Name einer eigenen Prozedur angegeben werden, welcher einen eigenen Basis-Resolver für die getestete Anwendung enthält. Man kann auch mehrere eigene Resolver-Prozeduren erstellen und diese in einem 'CustomWebResolver installieren' Knoten frei orchestrieren. Dabei ist auch die Kombination mit einem in QF-Test vordefinierten Basis-Resolver möglich. Dessen Kurzname muss dann an erster Stelle der Liste stehen. Die Resolver-Konfigurationen werden dann in der angegebenen Reihefolge angewandt.

    base:
    - vaadin
    - myResolvers.Panels
    - myResolvers.otherClasses
    Beispiel 49.1:   Liste von Basis-Resolvern
Konfigurationskategorie genericClasses

In dieser Kategorie werden die Erkennungsmerkmale festgelegt, aufgrund derer einem GUI-Element eine bestimmte generische Klasse zugewiesen werden soll. Die jeweiligen Eigenschaften der generischen Klassen sind in Kapitel 59 erläutert.

Generische Klassen können eine Typerweiterung erhalten. Diese ist beim Mappen bestimmter HTML-Elemente wie z.B. Item relevant: Item:ListItem bezeichnet Listenelemente, Button:ComboBoxButton einen Button innerhalb einer Combobox. Typerweiterungen sind auch deshalb interessant, weil sie beim Mapping frei vergeben werden können. Das Beispiel in 'CustomWebResolver' – Tabelle verwendet diese Technik.

Hinweis Bei der Verwendung der Typerweiterung in der Klassenangabe von SmartIDs ist zu beachten, dass der Doppelpunkt vor einer eigenen Typerweiterung durch einen Rückstrich geschützt werden muss. Siehe auch SmartID-Syntax für 'Klasse'.

Die angegebenen Einträge werden von oben nach unten evaluiert, für jedes HTML-Element wird die oberste zutreffende generische Klasse verwendet. Einzige Ausname hiervon bilden Einträge mit ancestor, diese werden immer als erstes evaluiert.

Für die Komponentenerkennung stehen grundsätzlich der Tag-Name und die Attribute des GUI-Elements zur Verfügung. Das Attribut class hat eine Sonderrolle. Es enthält die CSS-Klassen, die in der HTML-Prgrammierung die Darstellung des GUI-Elements beeinflussen und somit häufig charakteristisch für eine bestimmte HTML-Elementenklasse sind.

'CustomWebResolver installieren' bietet die Möglichkeit, jeden dieser drei Fälle als Zuweisung zu verwenden:

CSS-Klasse

Die CSS-Klasse bezieht sich auf einen Eintrag im Attribut class des GUI-Elements. Bitte beachten Sie, dass zwar mehrere CSS-Klassen durch Leerzeichen getrennt im Attribut stehen können, jedoch immer nur eine einzelne Klasse angesprochen wird.

Einfache Zuweisung: die CSS-Klasse wird in der gleichen Zeile hinter die generische Klasse geschrieben.

genericClasses:
- Button: btn
Beispiel 49.2:   Einfache Zuweisung CSS-Klasse zu generischer Klasse

Im Beispiel erhalten nur HTML-Elemente mit der CSS-Klasse btn die generische Klasse Button.

Zuweisung bei mehreren Kriterien: die CSS-Klasse wird eingerückt in einer Zeile unter der generischen Klasse mit dem Präfix css: eingetragen.

genericClasses:
- Button:
    css: btn
    tag: DIV
Beispiel 49.3:   Zuweisung CSS-Klasse und Tag-Name zu generischer Klasse

Im Beispiel erhalten nur HTML-Elemente mit der CSS-Klasse btn und dem Tag DIV die generische Klasse Button.

HTML-Tag-Name

Einfache Zuweisung: der Tag-Name wird in spitzen Klammern in der gleichen Zeile hinter die generische Klasse geschrieben.

genericClasses:
- TableCell: <TD>
Beispiel 49.4:   Einfache Zuweisung Tag-Name zu generischer Klasse

Im Beispiel erhalten nur HTML-Elemente mit dem Tag TD die generische Klasse TableCell.

Zuweisung mit mehreren Kriterien: der Tag-Name wird eingerückt in einer Zeile unter der generischen Klasse mit dem Präfix tag: eingetragen.

genericClasses:
- TableCell:
    tag: TD
    ancestor: TableRow
Beispiel 49.5:   Zuweisung Tag-Name mit ancestor zu generischer Klasse

Im Beispiel erhalten nur HTML-Elemente mit dem Tag TD die generische Klasse Button, wenn sie in einem GUI-Element der Klasse TableRow liegen.

HTML-Attribut

Einfache Zuweisung: der Attributname, ein Gleichheitszeichen und der Attributwert werden in der gleichen Zeile hinter die generische Klasse geschrieben.

genericClasses:
- TableRow: role=datarow
Beispiel 49.6:   Einfache Zuweisung Attributwert zu generischer Klasse

Im Beispiel erhalten nur HTML-Elemente mit dem Attribut role und dem Wert datarow die generische Klasse TableRow.

Zuweisung mit mehreren Kriterien: Eingerückt unter der generischen Klasse werden eine Zeile für den Attributname mit dem Präfix attribute: und eine Zeile für den Attributwert mit dem Präfix attributeValue: eingetragen.

genericClasses:
- TableRow:
    attribute: role
    attributeValue: datarow
Beispiel 49.7:   Zuweisung Attributwert zu generischer Klasse

Im Beispiel erhalten nur HTML-Elemente mit dem Attribut role und dem Wert datarow die generische Klasse TableRow.

Hinweis Auch das Attribut class kann hier genutzt werden. Dann muss jedoch der gesamte Wert des Attributs passen, damit die Zuweisung erfolgt. Wenn zum Beispiel zwei CSS-Klassen vorhanden sein müssen und die anderen ignoriert werden sollen, bietet sich ein regulärer Ausdruck an. Dies ist auch ein Beispiel für eine weitere Definitionsebene.

genericClasses:
- TableRow:
    attribute: class
    attributeValue:
        value: (^|.*\s)btn(\s.*|$)
        regex: true
Beispiel 49.8:   Zuweisung Attributwert zu generischer Klasse
Ancestor

Um eine Zuweisung zusätzlich abhängig von dem Vorhandensein eines bestimmten übergeordneten Elements zu machen wird ancestor: genutzt.

Einfache Zuweisung: die Klasse des Containers wird in der gleichen Zeile hinter das Präfix ancestor: geschrieben.

genericClasses:
- TableRow:
    tag: TR
    ancestor: Table
Beispiel 49.9:   Einfache Ancestor-Zuweisung

Im Beispiel erhalten nur HTML-Elemente mit dem HTML-Tag TR die generische Klasse TableRow, die irgendwo innerhalb eines Elements mit der Generischen Klasse "Table" liegen.

Komplexe Zuweisung: Eingerückt unter dem Präfix ancestor: folgen eins oder mehrere der der Präfixe type:, level: und className:.

Verfügbare Werte für type: sind ancestor (beliebige Verschachtelung), parent (direkt innerhalb des übergeordneten Elements) und interestingparent (direkt innerhalb des QF-Test Elements von node.getInterestingParent()).

genericClasses:
- TableRow:
    tag: TR
    ancestor:
        type: ancestor
        level: 2
        className: TableRow
Beispiel 49.10:   Komplexe Ancestor-Zuweisung

Im Beispiel erhalten nur HTML-Elemente mit dem HTML-Tag TR die generische Klasse TableRow, die zwei Ebenen tief innerhalb eines Elements mit der Generischen Klasse "Table" liegen.

Die Attribute css: und attributeName: können zwar mit tag: kombiniert werden, jedoch nicht miteinander.

Wenn HTML-Elemente mit unterschiedlichen Erkennungsmerkmalen die gleiche generische Klasse erhalten sollen, werden für diese Klasse zwei Einträge vorgenommen:

genericClasses:
- TableRow:
    attribute: role
    attributeValue: datarow
- TableRow:
    tag: TR
    ancestor: Table
Beispiel 49.11:   Gleiche generische Klasse für unterschiedliche HTML-Elemente

Hinweisancestor ist auch in vielen anderen Konfigurationskategorien verfügbar. Prüfen Sie dafür das Editier-Menü Editier-Button auf den Eintrag "Ancestor hinzufügen".

Konfigurationskategorie ignoreTags

Eine Liste von Klassennamen oder Tags, für deren Komponenten keine Knoten in der Komponentenhierarchie erstellt werden, solange diese nicht durch andere Anweisungen gemappt werden. Um Tags von Klassennamen zu unterscheiden, müssen Tags in Großbuchstaben oder zwischen spitzen Klammern angegeben werden.

Zum Beispiel werden durch den folgenden Eintrag alle DIV und TBODY Elemente, die nicht anderweitig gemappt wurden und mit denen nicht direkt interagiert wird, bei der Erstellung des Komponentenbaums ignoriert:

ignoreTags:
- <DIV>
- <TBODY>
Beispiel 49.12:  ignoreTags
Konfigurationskategorie ignoreByAttributes

Eine Liste von HTML-Attributnamen und -Werten, für deren Komponenten keine Knoten in der Komponentenhierarchie erstellt werden:

ignoreByAttributes:
- id: container
Beispiel 49.13:  ignoreByAttributes
Konfigurationskategorie autoIdPatterns

Eine Liste von Mustern, aus denen abgeleitet werden kann, ob Ids automatisch über das Framework generiert wurden. Falls das id Attribut dem Muster entspricht, wird der Wert nicht für das 'Name' Attribut der Komponente verwendet:

autoIdPatterns:
- myAutoId
- value: auto.*
  regex: true
Beispiel 49.14:  autoIdPatterns
Konfigurationskategorie customIdAttributes

Eine Liste von Attributnamen, deren Werte als Ids für die Komponente verwendet werden können. Beachten Sie, dass Sie das Attribut "id" hier mit aufnehmen müssen, wenn Sie das Standardverhalten von QF-Test nur ergänzen möchten.

Das folgende Beispiel bewirkt, dass ausschließlich das Attribut myid als Komponenten-ID interpretiert wird.

customIdAttributes:
- myid
Beispiel 49.15:  customIdAttributes
Konfigurationskategorie interestingByAttributes

Eine Liste von Attribut-Wert-Paaren, die angeben, ob eine Komponente für die Wiedererkennung interessant ist und somit ein Knoten dafür in der Komponentenhierarchie erstellt werden soll.

interestingByAttributes:
- id: container
- id: header
Beispiel 49.16:  interestingByAttributes
Konfigurationskategorie attributesToQftFeature

Eine Liste von Attributnamen, deren Werte für das 'Merkmal' Attribut der Komponente verwendet werden sollen.

Konfigurationskategorie redirectClasses

In dieser Kategorie können Sie für einzelne generische Klassen konfigurieren, ob Events an Elemente dieser Klasse weitergeleitet werden sollen oder bevorzugt ein Elternelement aufgezeichnet werden soll. Sie können auch mehrere Regeln definieren, um abhängig von der Klasse des Elternelements unterschiedliches Verhalten zu erreichen.

Einträge werden von oben nach unten evaluiert und nur der erste passende Eintrag angewendet.

Mit Vorsicht verwenden! Falls Sie sich unsicher sind, wenden Sie sich bitte an das QF-Test Supportteam.

Konfigurationskategorie documentJS

Javascript-Code, der in die Webseite eingebettet werden soll. Kann verwendet werden, um benutzerspezifische JavaScript-Funktionen einzufügen oder bei jedem Seitenaufruf bestimmten JavaScript-Code auszuführen.

Beachten Sie im folgenden Beispiel die Syntax für mehrzeilige Zeichenketten in YAML. Injizierter JavaScript-Code sollte möglichst keine Leerzeilen enthalten, um keinen Konflikt mit der YAML-Syntax auszulösen.

documentJS: |-
  window.hello = function() {
      console.log("Hello World");
  }
  hello();
Beispiel 49.17:  documentJS
Konfigurationskategorie attributesToQftName

Eine Liste von Attributnamen, deren Werte für das 'Name' Attribut von Komponenten verwendet werden sollen.

Konfigurationskategorie nonTrivialClasses

Eine Liste von CSS-Klassen, für die die zugehörigen Elemente von QF-Test nicht ignoriert werden sollen. Triviale Elemente sind normalerweise I, FONT, BOLD etc., es sei denn sie haben eine der angegebenen CSS-Klassen.

Mit Vorsicht verwenden! Falls Sie sich unsicher sind, wenden Sie sich bitte an das QF-Test Supportteam.

Konfigurationskategorie browserHardClickClasses

Eine Liste von Klassen, auf deren Komponenten immer harte oder semi-harte Events abgespielt werden sollen, z.B. spielt der Eintrag Button harte Klicks auf Buttons ab. Kann auf bestimmte Browser eingeschränkt werden.

Konfigurationskategorie treeResolver

Diese Kategorie bündelt Konfigurationsmöglichkeiten, die den Umgang von QF-Test mit Baumknoten in Tree und TreeTable steuern. Verwenden Sie diese Kategorie falls QF-Test in Ihrer Anwendung Schwierigkeiten hat, die Hierarchieebenenen von Bäumen zu unterscheiden, einzelne Baumknoten ein- und auszuklappen, oder den Textinhalt von Baumknoten korrekt auszulesen.

Konfigurationskategorie treetableResolver

Diese Kategorie bündelt Konfigurationsmöglichkeiten, die den Umgang von QF-Test mit Baumknoten in TreeTable-Komponenten steuern. Hier können Sie beispielsweise angeben, in welchem Spaltenindex der Tabellen Ihrer Anwendung sich ein Baum befindet, falls QF-Test diesen nicht automatisch bestimmen kann.