Comment automatiser vos tests logiciels en utilisant C#, BDD et Spekflow ?

La plupart des frameworks d’automatisation Sélénium utilisent Java et les frameworks de tests associés, par exemple JUnit, TestNG. Cependant en ce qui concerne les projets utilisant les technologies Microsoft, il peut etre utile de travailler avec C # et SpecFlow. Cet article présente l’approche à utiliser pour automatiser avec C# BDD et Spekflow.

1. Test automatique avec C# BDD et Spekflow

L’automatisation des tests est l’utilisation de logiciels :

  • Pour définir les conditions préalables de test.
  • Pour contrôler l’exécution des tests.
  • Comparer les résultats réels aux résultats prévus.

L’automatisation est une méthode qui nécessite l’intervention des solutions informatiques et d’algorithmes pour exécuter un script et analyser le produit sur des parcours bien précis.

Pourquoi et quand automatiser en utilisant C# BDD et Spekflow ?

L’objectif principal de l’automatisation est de réduire le temps de test des zones qui ont déjà été testées au même niveau qualitatif. Ainsi on évitera la perte de temps, argent et effort humain.

  • Tests de régression fréquents
  • Exemple de test répété
  • Tests d’acceptation par l’utilisateur
  • Feedback plus rapide aux développeurs
  • Testez la même application sur plusieurs environnements

2. Environnements et Outils d’automatisation de test Sélénium WebDriver BDD et Spekflow

2.1 Sélénium WebDriver

Sélénium WebDriver a été développé pour mieux supporter les pages web dynamiques où les éléments d’une page peuvent changer sans que la page elle-même soit rechargée. L’objectif de WebDriver est de fournir une API orientée objet bien conçue qui offre une meilleure prise en charge des problèmes de test avancés d’applications Web modernes.

2.2 Approche BDD

           Le  BDD (Behavior Driven Development)est une méthode agile qui encourage la collaboration entre les développeurs, les responsables qualités, les intervenants non-techniques et les analystes participant à un projet de logiciel.

Le BDD est présenté comme une évolution du TDD (Test Driven Development).

  • le BDD va guider le développement d’une fonctionnalité, tandis que le TDD guidera son implémentation.
  • Il s’agit d’écrire des tests qui décrivent le comportement attendu du système et que tout le monde peut comprendre.

Les avantages du BDD

  • Un dialogue restauré

L’écriture des scénarios se fait de manière collective: développeurs, clients, équipe support, …: tout le monde peut participer à l’expression du besoin

  • Un développement guidé et documenté
  • Une documentation à jour et toujours disponible
  • Des tests en continu sur les fonctionnalités
  • Passer de la réflexion sur les «tests» à la réflexion sur le «comportement»

2.3 Qu’est-ce que SpecFlow ?

SpecFlow est un framework de test et un plug-in qui s’intègre avec Visual Studio, qui permet d’écrire des tests d’une manière naturelle, puis de les exécuter avec un dérouleur de tests.

SpecFlow est basé sur  la syntaxe Gherkin, une grammaire conçue pour écrire des spécifications de comportement.

2.4 Framework MStest

MSTest est un framework de test unitaire fourni par Microsoft Visual Studio qui possède des fonctionnalités intégrées pour prendre en charge les tests pilotés par les données, qui peuvent être configurées très facilement.

2.5 Différence entre Sélénium C # et Java

Il n’existe aucune différence majeure entre le développement des cas de test avec Sélénium « C # » et « Java », ce sont juste quelques modifications apportées ici et là pour prendre en charge le nouveau navigateur Firefox ou le chrome, etc. Dans ces deux langages, les modifications apportées au niveau du code sont:

3. Développement des cas de tests automatiques

3.1 Comment déterminer ce qu’on automatise avec C# BDD et Spekflow ?

Les critères pour choisir les cas de test à automatiser sont :

  1. La faisabilité technique de l’automatisation,
  2. La fréquence d’exécution des tests,
  3. Le degré de réutilisabilité des composants de test,
  4. Le nombre total de ressources nécessaires,
  5. La complexité des cas de test,
  6. La possibilité d’utiliser les mêmes cas de test pour de multiples navigateurs ou environnements
  7. Le temps nécessaire à l’exécution des tests

Le diagramme des différents critères pour sélectionner les cas de test à automatiser

Pour automatiser un cas de tests, nous devons commencer par la création d’un « fichier .Feature » 

3.2 Création d’un fichier .Feature

C’est un fichier dans lequel nous allons décrire nos tests en langage descriptif, un fichier de fonctionnalités peut contenir un scénario ou peut contenir plusieurs scénarios dans un seul fichier.

3.3 Générer les StepsDefinitions

Si la couleur des déclarations mentionnées dans le fichier est violet, cela signifie que ces déclarations ne sont associées à aucune définition. Cliquez avec le bouton droit sur le fichier de fonctions et sélectionnez « Générer les étapes des définitions ».

3.4 Déclaration des locators :

Les « locators » sont les variables déclarées dans les classes « XLocators» pour sélectionner les éléments HTML utilisés dans les cas de test.

Quelques exemples des locators :

  • Exemple par «ID »

[FindsBy(How = How.Id, Using = “Password“)]

publicIWebElement PasswordId;

  • Exemple par « XPATH »

[FindsBy(How = How.XPath, Using = “(.//*[normalize-space(text()) and normalize-space(.)=’Connexion’])[1]/div[1]”)]

publicIWebElement BtnConnexionXpath;

  • Le Syntaxe : [FindsBy(How= How.Id, Using = “username“)]
    privateIWebElement UserName { getset; } est utilisé pour marquer un champ sur un objet Page pour indiquer un mécanisme alternatif pour localiser un élément.
  • WebDriver fournit les types de requête de localisateur suivants à l’aide de «By»:
  • Class name
  • CSS Selector
  • ID
  • Link text
  • Name
  • Partial link text
  • Tag name
  • XPath

3.5 Développement des fonctions :

Les fonctions développées sont des actions qui seront ensuite utilisées dans les cas de test. Toutes les fonctions utilisées dans les cas de tests se trouvent dans “pageobject” de chaque module.

3.6 Développement des « Steps definitions »:

Dans les classes «XStepDefs », on appelle les fonctions déjà créés dans « XPage » pour exécuter le scénario souhaité.


4. Architecture et Design Patterns

4.1 Factory Pattern

En utilisant Factory Pattern, nous cachons complètement la logique de création des instances de navigateur / service aux classes de test. Si nous obtenons une nouvelle exigence pour ajouter un nouveau navigateur, par exemple PhantomJS, cela ne devrait pas être une grosse affaire. Nous avons juste besoin de créer un PhantomJSDriverManager  qui étend DriverManager.

4.2 Modèle d’objet de page (POM)

C’est un modèle de conception permettant de créer un référentiel d’objets pour les éléments d’interface utilisateur Web. Sous ce modèle, pour chaque page Web de l’application, il devrait y avoir une classe de page correspondante. Cette classe Page trouvera les WebElements de cette page Web et contient également des méthodes de page qui effectuent des opérations sur ces WebElements.

4.3 Les Hooks de SpecFlow

Vu qu’on rencontre des situations dans lesquelles on doit effectuer les étapes préalables avant de tester un scénario de test. Cette condition préalable peut être:

  • Démarrer un webdriver
  • Configuration de connexions DB
  • Configuration des données de test

De la même manière, il y a toujours des étapes après les tests comme:

  • Tuer le webdriver
  • Effacer les données de test
  • Effacer les cookies du navigateur
  • Déconnexion de l’application
  • Impression de rapports ou de journaux
  • Prendre des captures d’écran sur l’erreur

Pour gérer ce genre de situations, les Hooks de SpecFlow sont le meilleur choix à faire en utilisant les méthodes [BeforeScenario] et [AfterScenario].

5. Exécution des cas de test :

5.1 Exécution avec l’IDE Visual Studio :

Une fois la construction réussie, nous devons ouvrir la fenêtre Test Explorer, la fenêtre Explorateur de tests s’ouvre avec la liste des tests disponibles. Cliquez avec le bouton droit sur Explorateur de tests et sélectionnez Exécuter les tests sélectionnés.

5.2 Exécution avec les fichiers « .bat » :

Il est possible aussi d’exécuter un ensemble de cas de test avec un fichier «.bat »

Le Syntaxe :

@echo off
cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\TestWindow
vstest.console.exe “*/.sln” /TestAdapterPath:C:\PATH\packages /ResultsDirectory: C:\PATH\packages \ /Tests:Smoke
pause

6. Rapport d’exécution de test :

L’ExtentReport est le rapport le plus connu utilisé avec Sélénium. L’API ExtentReport nous permet de générer facilement des rapports interactifs avec des configurations simples. Il supporte presque tous les frameworks de test Java et .NET tels que TestNG, JUnit, NUnit, etc.

 


7. Automatisation des tests sur les pipelines Azure :

  • Configurer l’agent :

Sélénium exige que l’agent soit exécuté en mode interactif pour exécuter les tests.

  • Configurer l’agent : cmd
  • Démarrer l’agent : cmd

  • Configurer le pipeline : 

« TestCategory » est un paramètre permettant d’exécuter un ensemble de cas de test fonction de la condition de filtrage.

  • Exécution du test Sélénium:

  • Analyser les résultats du test :

Conclusion :

Sélénium WebDriver est un framework de test de logiciel efficace permettant d’effectuer des tests fonctionnels et de régression. Pour tirer le meilleur profit de son utilisation, vous devez appliquer les bonnes pratiques et disposer d’une bonne architecture dès le début.

Voir aussi notre offre sur l’automatisation des tests.

Rédacteur : Zied Hannachi / Consultant test automation All4test

Vous avez une question technique sur le sujet ? Vous avez un projet d’automatisation de test ?

Contactez-nous