Loupe

Selenium Driver : Derrière la scène !

Introduction

Après avoir vu comment démarrer sur Selenium multi-navigateurs en 1 package NuGet dans un précédent article, il est temps de clarifier un peu la magie mise en place derrière tout ça 😊.

Je résume le processus pour démarrer via Visual Studio :

  • Créer un nouveau projet de test MSTest ou XUnit
  • Référencer le package WebDriver
  • (Optionnellement référencer les packages NuGet des navigateurs cibles tels que Selenium.WebDriver.ChromeDriver, Selenium.Firefox.WebDriver, )
  • Instancier un nouveau RemoteWebDriver (ChromeDriver, FirefoxDriver, etc.)
  • Appeler les méthodes Navigate() pour naviguer vers une page, FindElement() pour intéragir avec les contrôles, etc.
  • Ne pas oublier d’appeler Quit() ou Dispose() pour fermer les navigateurs proprement

Exemple de code Selenium :

b01-test-selenium-simple-csharp.PNG

Voyons plus en détail la partie WebDriver.

Architecture du fonctionnement de Selenium

Prenons par exemple le cas du ChromeDriver : Celui-ci nécessite donc l’installation des 2 packages NuGet Selenium.WebDriver ainsi que Selenium.WebDriver.ChromeDriver. Le fonctionnement est le suivant :

  • Du code C# permettant de piloter les tests Selenium est écrit (1), tirant parti des classes génériques RemoteWebDriver, etc. contenus dans la librairie WebDriver.dll (2)
  • Les instructions sont ensuite traduites en requêtes HTTP POST, suivant le récent standard W3C du WebDriver Protocol, standard suivi par les navigateurs les plus classiques (Chrome, Firefox, Edge, etc.), et sont envoyées au chromedriver.exe (3)
  • Le chromedriver.exe quant à lui est une web application self hostée, qui expose des endpoints http en POST, et qui se charge de communiquer avec les navigateurs cibles : par exemple dans le cas de chrome, les instructions sont envoyées à chrome.exe (4) via les WebSockets des DevTools de remote debugging et pour Firefox, c’est le Firefox remote protocol qui est utilisé pour communiquer.

b02-architecture-selenium-webdriver.PNG

Pour illustrer ce fonctionnement, je propose une petite démonstration, qui illustre comment communiquer avec le chromedriver.exe directement en requêtes http POST via Postman 😊

Selenium4fun : Piloter Selenium via Postman

Commençons par aller voir du côté du package NuGet Selenium.WebDriver.ChromeDriver. Celui-ci contient donc notre fameux chromedriver.exe :

b03-selenium-chromedriver-dans-package-nuget.PNG

Si on l’éxécute, une fenêtre console apparait expliquant que le driver est disponible sur le port 9515

b04-chromedriver-self-hosted.PNG

Essayons maintenant de communiquer avec notre driver en lui envoyant une requête http POST via Postman :

b05-postman-requete-chromedriver.PNG

L’envoi de notre requête http a plusieurs effets :

  • Tout d’abord, elle ouvre Chrome 

b06-chrome-test-est-ouvert-par-http-post.PNG

  • Mais surtout elle nous renvoit tout un tas d’informations, notamment le sessionId qui peut être ensuite réutilisé dans les appels http POST ultérieurs pour piloter Chrome.

Exemple de navigation vers une url :

b07-ouverture-de-bing-via-http-post.PNG

Et voilà 😊

Note: Vous pouvez retrouver la liste des endpoints du standard W3C WebDriver Protocol sur le site officiel du w3c

Conclusion

Nous avons vu dans cet article le fonctionnement de l’architecture mise en place par Selenium, connaissance qui n’est évidemment pas obligatoire, mais toujours intéressante à savoir pour pouvoir être plus pertinent en cas d’erreur sur les webdrivers.

Il faut savoir également que comme les navigateurs évoluent très vite, ces drivers sont également amenés à monter de version très fréquemment (erreur simple de problème de communication entre le webdriver et le navigateur). Heureusement pour nous, les packages NuGet contenant ces drivers facilitent grandement cette maintenance, et là où il était nécessaire de télécharger les nouveaux webdrivers pour chaque nouvelle version, il suffit maintenant de mettre à jour le package de NuGet !

Pour aller plus loin, imaginons qu'au lieu d'avoir des Drivers pour piloter des navigateurs web, nous avions des Drivers pour piloter des applications Mobiles (iOS, Android) ou même Desktop (MacOSX, Windows) : c'est en partant de ce postulat de base que l'initiative Appium est née, basée sur une architecture binding/driver similaire à Selenium, et qui permet donc de piloter des applications desktop ou mobile,  :)

Photo de profil

Ces billets pourraient aussi vous intéresser

Vous nous direz ?!

Commentaires

comments powered by Disqus