Alle Beiträge von Michael Wowro

Ranorex Entitäten: Role, Capabilities & Characteristics / Adapter & Element / RepoItem & RepoItemInfo

Role, Capabilities & Characteristics

Allgemein

Das Schaubild aus der Offiziellen Doku:

Im Prinzip geht es immer um Attribute und ihre Werte – das ist für die alltägliche Testautomatisierungs-Praxis das Wesentliche. Die Bedeutung des obigen Schaubilds liegt eher im theoretischen Bereich und zeigt, woher Ranorex Spy die Attribute bekommt und wie es diese zusammenfasst.

Technology bezieht sich wohl auf die Technologie mit der die Application Under Test umgesetzt ist, also z.B. Web, Office, Java, SAP, usw. Jedenfalls die Technologie aus Sicht von Ranorex. Im Desktop-Bereich können das mehrere gleichzeitig sein – im Web-Bereich hingegen ist das ganz einfach: es geht immer um die Webtechnologie, also um die Attribute des Bereichs Web Plugin.

Categories (im Bereich Capabilities) sind die blauen Überschriften:

Tatsächlich sind es 18 (im Schaubild ist die Rede von 15+) und werden alle mit Plugin postfixt und meint die Technologie im Sinne Ranorex. Im Ranorex attributes overview ist zusätzlich noch ganz oben die Kategorie build in roles aufgelistet, wobei m.E. die Spaltenüberschrift hier nicht Capabilities sondern eben Roles lauten müsste.

Beispiel: Google-Logo

Ich habe das Google-Logo mit dem Ranorex Spy getrackt – Folgendes steht nun im Advanced-Tab des Ranorex Spy:

Im Gegensatz zu einer Desktopanwendung hat das Element schon mal die Role Unknown, weshalb auch keine Rollen-spezifische Überschrift im AdvancedTab zu sehen ist.

Als PreferedCapability ist ImgTag angezeigt, wobei das wohl dem Primary Adapter entspricht, der ganz links oben neben dem vorgeschlagenen Namen steht.

Die Attribute im Ranorex Attribute Overview stimmen mit denen im Advanced Tab von Ranorex Spy exakt überein.

Ranorex Spy in action

Am besten macht man sich den Unterschied der ganzen Begrifflichkeiten anhand des Ranorex Spy -> Track -> Hovern über ein bestimmtes Element und studieren des kurz später auftauchenden Tooltips klar:

Im Header:

  • Icon für den nachfolgende Primary Adapter.
  • Primary Adapter: die Haupt-Capability
  • Von Ranorex vorgeschlagener Name in einfachen Anführungszeichen

Role spezifiziert, welche Funktion ein Steuerelement (unabhängig von der verwendeten Technologie) hat, also z.B. handelt es sich um einen Button oder um ein Textfeld (egal ob in einer Webanwendung oder in einer ASP.net-Anwendung). Für die Web-basierte Testautomatisierung hat die Role keine Bedeutung, da Ranorex Spy dort die UI-Elemente ohnehin immer als Unknown kennzeichnet.

Caps: Capabilities. Im Web ist das immer das WebElement und eine spezifischere Capability (also z.B. imgtag). Die spezifischere Capability wird im Header immer als primary adapter angezeigt.

Location: wo beginnt das Element relativ zum Viewport in Pixel

Size: wie groß ist das Element in Pixel

Attributes: alle Begriffe in blauer Schrift. Kennzeichnet die kleinsten Einheiten in diesem Begriffsdschungel, nämlich z.B. Visible oder InnerText

Beispiel Keepass-Button OK

Ich habe den OK-Button beim Windows New Entry in Keepass getracked.

Die Überschriften Button, Control und NativeWindow im Advanced-Tab des Ranorex Spy:

… finden sich im Ranorex attributes overview wieder:

Adapter & Element

Adapter

Capabilities (z.B. ImageTag) sind im Ranorex-Code als Adapter implementiert:

Auch Roles (z.B. Button) sind in Ranorex als Adapter implementiert:

Click() ist beispielsweise eine Methode des Adapters.

Der generierte Ranorex-Code leitet den Adapter aus dem entsprechenden Repoitem her:

Darüber hinaus zählt der Adapter zahlreiche Properties – die Auswahl der wichtigsten:

  • Screenrectangle (Advanced -> Layout) beschreibt X- und Y-Position (ausgehend von der linken oberen Monitorecke) sowie Breite und Höhe. Exakt diese Daten in genau dieser Reihenfolge werden auch optisch unter dem Titel herausgehoben:
  • Flavorname (Advanced -> General) gibt einen Hinweis auf das dahinterliegende Gebilde. Werte von Elementen einer Desktop-Anwendung sind bsps.weise msaa, winforms, win32, chromeweb
  • Location (Advanced -> Dynamic) gibt die X- und Y-Position (ausgehend von der linken oberen Ecke des Parent-Elements) an. (Achtung: Es gibt in Ranorex auch irritierenderweise eine Klasse Ranorex.Location, deren x- und y-Werte jedoch die Distanz zur oberen linken Ecke des Elements selbst darstellt.)

MyRepoObject.Element.Location.X

WebElement ist eine Subklasse von Adapter und hat z.B. die zusätzliche Methode getInnerHTML():

Element

Element im allgemeinen Sinne

Bestandteil einer UI.

Element (im Sinne der Ranorex-library)

Dieser Post fasst die aktuellen(?) Unklarheiten gut zusammen – ein user postete einen interessanten Erklärungsversuch.

Hier ein Post, der das Verhältnis von Element und Adapter skizzieren dürfte.

RepoItem, RepoItemInfo & Adapter

RepoItem

RepoItem: am 17.8.2022 habe ich bei einem <i>-Element die Beobachtung gemacht, dass Ranorex, wenn es mit dem entsprechenden RanoreXPath eigentlich mehrere <i>-Elemente auf der Webseite selektieren würde, es nur das erste nahm.

RepoItemInfo

RepoItemInfo: What’s a RepoItemInfo and how do you use it? – Ranorex Forum

Eine in einer Actiontable erzeugte Validierungsaction, nutzt im dahinterliegenden Code nicht das repoItem, sondern das repoItemInfo, z.B.

Validate.Exists(repo.StartPage.SuchfeldInfo);

Ein in einer Actiontable erzeugtes Wait, nutzt im dahinterliegenden Code ebenfalls das repoItemInfo, z.B.

repo.StartPage.SuchfeldInfo.WaitForExists(5000);
//oder:
repo.StartPage.SuchfeldInfo.WaitForAttributeEqual(5000, "Id", "yourValue");

Ein repoItem hat gar keine WaitForExists-Methode:

und auch keine sonstige Wait-Methode …

Wie komme ich von RepoItemInfo zu Adapter

Es gilt jedoch zu beachten, dass FindAdapter<WebElement>() immer einem spezifischen Adapter vorzuziehen ist, weil bei der Änderung eines Elements von beispielsweise <div> auf <td> folgende Fehlermeldung kommt:

Item myRepository.okButton is no DivTag.
The element does not support the required capability ‚divtag‘.

Wie komme ich von RepoItem zu Adapter

var okButtonAdapter = myrepo.okButton; // hier wird der Adapter erzeugt, der im repository item gespeichert ist, beispielsweise WebElement
okButtonAdapter.Click();

Wie komme ich von Adapter zu RepoItemInfo

aktuell gar nicht (Quelle)

mit Hilfe von Adapter.GetPath() bekommt man zwar einen RanoreXPath, dieser ist jedoch nicht der ursprünglich vom Testautomatisierer eingegebene, sondern ein „künstlich“ generierter:

string RxPath = webElement.Element.GetPath(PathBuildMode.Default);

MSB4018: Unerwarteter Fehler bei der ResolveAssemblyReference-Aufgabe

Heute morgen hat sich der Builder von Visual Studio 2017 mal wieder „verschluckt“. Das bei jedem Fehler angegebene Projekt A war immer das gleiche. Und seltsamerweise lies sich das Projekt A alleine problemlos bauen. Es werden gleich 10 unterschiedliche Build-Errors ausgespuckt. Die betreffende Datei ist die Microsoft.Common.CurrentVersions.targets in der Zeile 1964. Bei jedem erneuten Buildversuch stieg die Zahl der Builderrors immer um 10 (10, 20, 30, 40, 50, 60, … Builderrors).

Workaround

Ich baue aktuell nicht mehr die komplette Solution, sondern nur noch die Projekte, die ich gerade brauche.

Erfolglose Lösungsversuche

  • Ich habe meinen Kollegen gebeten die Solution zu bauen und bei ihm hat es funktioniert.
  • Clean & Build hat nichts gebracht.
  • obj/bin von Projekt A manuell löschen (wie hier auf SO empfohlen) hat nichts gebracht.
  • Der fälschlich vermutete Lösungs-Hinweis war der Blick in die Verweise des Projekts A im Projektmappen-Explorer – fünf Verweise waren mit einem gelben Warnzeichen gekennzeichnet. Erst als ich ein so markiertes Projekt im Projektmappen-Explorer öffnete, erschien kurz eine Meldung, dass etwas im Hintergrund geladen würde und das entsprechende Warnzeichen verschwand. So tat ich es mit allen betreffenden Projekten. Dies hat jedoch nichts an den Buildproblemen der Solution verbessert.
  • Restart Windows, anschließender Clean & Build brachte keine Lösung. Der einzig interessante Effekt war, dass die Anzahl der Fehler wieder auf 10 sank. Bei jedem weiteren Solution-Build stieg die Anzahl der Fehler wieder jeweils um 10.