Webdriver für Chrome

Danke dir Marcel, dies ist verständlich 👌 .

Allerdings hört sich das so an, als wären die Credentials von findigen Mitarbeitern ggf. einsehbar. Der/die HTTP-Requests, auch die des WebDrivers (Chromedriver) sind ja nicht verschlüsselt und könnten mit etwas Energie beobachtet/herausgefischt werden. Klar, ein sehr skizziertes Szenario was vielleicht nicht relevant ist. Ich wollte es dennoch mal erwähnen 😅 .

Viele Grüße
Sven

Hi Marcel 👋 ,

ich hoffe wir langweilen mittlerweile hier niemand mit unserem Austausch. Falls doch, dann darf gern durch eine Moderator, Poweruser etc. darauf hingewiesen werden. Denn dann schlage ich vor, dass wir einen separaten Thread rund um die Arbeit mit WebDriver öffnen oder so.

Falls sich niemand daran hier stört, mache ich einfach weiter 😅 .

------------------------

Nun also zur Antwort:

Zitat von gmmg

habe mir mal dein Boilerplate Tutorial angesehen und auch Abonniert

Freut mich das du dir es angesehen hast, Danke auch fürs Abo 👌 .
_{PS.: Ein GitHub-Star würde mich noch viel mehr freuen 😅 .}

Zitat von gmmg

Was mir in der Struktur nicht gefällt, dass alle selector und page-objects in der Ebene 1 liegen. Schon bei einigen Websites wird es meiner Meinung nach unübersichtlich, wenn alles im Hauptpfad liegt.

Wie du dein Projekt strukturierst ist ganz dir überlassen. Das boilerplate template repository ist für die Browser Automation einer Website aufgebaut, daher gibt es keine Aufteilung nach Webseiten oder so.

Zitat von gmmg

Ich stelle mir die Aufteilung eher so vor. Hat das irgendwelche Nachteile gegenüber deiner Aufteilung? Was meinst du dazu?

Das kannst du auf jeden Fall so machen ohne starke Nachteile zu haben. Musst dann einfach nur die #includes entsprechend einmalig anpassen, ansonsten geht auch dies.

Empfehlung:
Ich rate allerdings davon ab mehrere Projekte, respektive Webseiten, in einem Repository/Projekt abzubilden. Zumindest wenn es um diverse Test Automation Schritte geht, die pro Webseite dann auch abgebildet werden sollen. Mit anderen Worten, wenn es umfangreich werden wird, dann rate ich davon ab und rate zu einzelnen Projekten. Üblicherweise würde man, so machen es viele Hersteller/Communities (wie Selenium, WebdriverIO, Nightwatch, Playwright etc.) vor, pro Website ein Projekt (ein Repo.) aufbauen. Damit du dennoch Redundanzen zwischen den Projekten vermeidest, würde dann bspw. mit Git Submodules gearbeitet. Aber auch dies ist kein Muss.

Zusammenfassend:
Du kannst wenn die Schritte ggf. nicht zu umfangreich sind, deine vorgeschlagene Struktur nutzen.
Könnte dann wohl etwa so aussehen.

Du kannst auch per Browser-Tab eine Website bearbeiten/automatisieren, also drei auf einmal (in jeweils einem Tab).
Du kannst auch drei Driver-Instanzen laufen lassen und jeweils dort die Schritte automatisieren. Dies ist allerdings recht aufwändig, zugegebenermaßen.

Also ich würde es abhängig vom Umfang machen und entscheiden. So wie du bisher beschrieben hast, was getan wird, finde ich deinen Ansatz pro Webseite legitim und sogar sinnvoll 😀 . Wenn es wächst wirst du dann ja merken ob es umstrukturiert werden sollte oder nicht.

Viele Grüße
Sven

Hi Marcel 👋 ,

mal von hinten nach vorn. Bei der Lotto-Thüringen Seite ist es recht einfach.
Nimm den XPath den du hast - wahrscheinlich über den Browser generieren lassen, richtig 😀 ?
Oder nimm diesen //div[@id="ccm-widget"]//button[text()="Alle akzeptieren"].

------------------------

Bei der ersten Seite, ist der Usercentrics Cookie Consent Dialog im Shadow DOM (nach)geladen. Daher kommst du auch mit XPath dort nicht heran.
Dies ist eine bekannte Einschränkungen, falls es nicht mittlerweile anders sein sollte. Was du tun kannst ist entweder über CSS Selector gehen (wobei das mit ziemlicher Sicherheit auch nicht funktionieren wird) oder besser den Klick per Javascript senden.

------------------------

Eine recht gute Erläuterung zum 🔗 ShadowDOM .

Ich schaue mal ob ich zeitnah dazu komme dir eine entsprechende Funktion zu basteln, sollte nicht lang dauern.
Doch ich würde es natürlich testen wollen, daher etwas Geduld 🤝 .

Viele Grüße
Sven

Wunderbar, falls dies für dich so funktioniert. Ich weiß nicht ob die Klasse ".sc-dcJsrY.dWLoUN" sich verändern wird (also dynamisch ist), daher würde ich über das data-testid Attribute gehen. In etwa so, auch wenn ich es nur JavaScript seitig im Browser getestet habe (DevTools), sollte es genauso auch im WebDriver Skript funktionieren. Kannst du ja gern mal ausprobieren 😀 .

1. Suche im Dokument das Element vor dem "shadow-root (open)" Bereich.
   ==> Das DIV mit der ID "#usercentrics-root" (CSS Selector).
2. Suche den Button "Alles Akzeptieren" innerhalb des Bereichs (des ShadowDOM).
   ==> Ebenfalls CSS Selector, "button[data-testid='uc-accept-all-button']".
3. Klick das gefundene Element, fertig.
   ==> .click()

_ClickShadowDomElement('#usercentrics-root', 'button[data-testid="uc-accept-all-button"]')

Func _ClickShadowDomElement($sCssSelectorBeforeShadowRoot, $sCssSelectorTargetInShadowDom)
    Local $sJavaScriptCode = StringFormat( _
        'document' & _
            '.querySelector("%s")' & _
            '.shadowRoot.querySelector("%s")' & _
            '.click();', _
        StringReplace($sCssSelectorBeforeShadowRoot, '"', "'"), _
        StringReplace($sCssSelectorTargetInShadowDom, '"', "'"))

    _WD_ExecuteScript($sSession, $sJavaScriptCode)
EndFunc

Viele Grüße
Sven

Update: Nach Hinweis im Post #30 ist der Code hier (Post #29) nun korrigiert und funktioniert wie gewünscht.

Danke Marcel, ja das liegt einfach daran, dass ich ein "s" bei #usercentric-root vergessen habe.
Es muss #usercentrics-root heißen (ist korrigiert oben im Post #29) und ich konnte es auch erfolgreich testen - funktioniert wunderbar 😁 .

Allerdings überlege ich noch ob die Funktion _WD_GetShadowRoot besser ist, als das JavaScript selbst zusammenzubauen und dann per _WD_ExecuteScript abzuschicken (so wie in meinem Beispiel/Vorschlag) 🤔 . In erster Betrachtung ja, allerdings gibt es manchmal ShadowRoots, welche verschachtelt sind. Dann musst du immer von ShadowDomElement zu ShadowDomElement hangeln, um dann das eigentliche Element auszuwählen. Somit müsste man mehrfach mit _WD_GetShadowRoot arbeiten, anstatt direkt im JavaScript die Sprünge zu machen.

Beispiel hier. Am Ende vielleicht einfach nur Geschmackssache.
Hauptsache du hast eine Lösung für deinen Anwendungsfall 👌 .

Viele Grüße
Sven

Hi Marcel 👋 ,

ich denke du musst gar nicht jedes Mal das Update durchführen lassen. Du kannst auch erstmal prüfen, ob sich die Browser- und damit die Driver-Version geändert hat oder ändern muss und dann erst das Update durchführen lassen. Also den Download des neuen drivers.

Dazu kannst du dir die Remarks (wd_helper.au3 > Zeile 2055) mal anschauen - da steht der Hinweis dazu.

Zitat von gmmg

Hast du da bereits etwas umgesetzt, um den Status / Fortschritt des Updates anzuzeigen? Meine Idee war jetzt, vor und nach dem _WD_UpdateDriver einen TrayTip anzuzeigen, damit der User hier weiß, das noch was passiert.

Nein dafür habe ich nichts implementiert oder so. TrayTip oder ToolTip ist völlig valide meiner Ansicht nach. Oder du blendest einen Spinner als Loading Indicator ein oder so.
So'n Kram 😅 , gibt es sicherlich schon X-Mal nehme ich an.

Siehst du da tatsächlich irgendein Verbesserungspotenzial auf seiten des WebDrivers?
Denn streng genommen ist es ja davon abhängig wie gut deine Internetverbindung und Download etc. ist. Also auf User-Seite.
Ich lasse mich aber gern von guten Vorschlägen überzeugen das man da was machen sollte 😇 .

Viele Grüße
Sven