BDD

Behavior Driven Development

Cédric BRASSEUR
Mis à jour le 22/04/2025

Cédric BRASSEUR

  • Ancien étudiant de l'Exia.cesi
  • 4 ans consultant chez Amaris, placé chez Euro Information Dev
  • Auto-entrepreneur depuis début 2020 (Création de sites web, applications mobiles & formateur)

Et vous ?

  • Nom, prénom
  • Etudes réalisées 
  • Behavior Driven Development en entreprise ?
  • Autres infos appréciées

Plan du cours

  • Introduction au BDD

    - Historique, objectifs, TDD, ATDD,...

     

  •  ATDD

    - Présentation d'une ATDD
    - Sélénium, WebDriver & Locator

    - Mise en place d'une ATDD complète (workshop guidé)

     

  • Principes associés au BDD

    - Notion de comportement & scénario

    - Format Gherkin& Exemple de scénario

     

  • BDD mise en pratique

    - Mise en place de scénario (en .NET avec SpecFlow), organisation des tests, architecture

BDD

Objectifs de la semaine

  • Réaliser une ATDD pour mise en place d'un micro Framework utilisable pour mettre en place du BDD
     
  • Comprendre la notion de comportement, de scénario et les avantages du BDD
     
  • Mise en place d'un BDD et appréhender ses avantages et sa forte plus value pour une entreprise

Introduction au BDD

Behavior Driven Development

Introduction - Historique

  • Behavior Driven Development a commencé à voir le jour en 2006, Kent Beck, grand utilisateur de TDD à l'époque s'est rendu compte que ses besoins en tests unitaires se transformais au fur et à mesure en besoins de tests d'acceptation.
    Dan North a ajouté la notion de comportement et au lieu de parler te tests, il parle de comportement à contrôler.
     
  • D'où la naissance de l'ATDD (Acceptance Tests Driven Development)
     
  • Puis par induction, et en se référant au modèle agile qui est de plus en plus utilisé, Behavior Driven Development a été mis en place pour démarrer les développements directement depuis les users stories 

Introduction - Objectifs

Objectifs BDD :

  • L'objectif premier est comme on l'a vu juste avant de partir des users stories (scénarios)
  • Ces scénarios sont directement écris en anglais (ou autre langue)
  • Chaque scénario est défini en plusieurs étapes
  • Chaque étape fera office de test unitaire ou test d'interface (plus souvent d'interface)
  • Le scénario sera quant à lui un test d'acceptation
  • On développe exactement ce qui est demandé, ni plus ni moins
  • Chaque élément est testé & couplé à une ATDD, les tests d'interfaces sont complets
  • Les tests peuvent être automatisés et exécutés en intégration continue
  • ...

(Graphique non représentatif)

BDD en vogue

Depuis son arrivée en 2006 / 2007, la popularité de la méthodologie de développement en se basant sur le comportement (BDD) n'a de cesse d'augmenter.

Pourquoi ?

Les avantages à l'usage

Vanguard Group Feedbacks

  • Un des premier grand utilisateur de BDD est le groupe Vanguard. Peu importe ce qu'ils font, ils ont publiés un article sur leur utilisation du BDD et les avantages qu'ils en ont tirés.

 

Voici la liste des avantages que j'ai pu en sortir :

  • Leur temps de développement de tests a diminué d'environ 40%
  • Le nombre de Defects (bugs) a diminué drastiquement
  • La durée pour mettre en production a diminué
  • La confiance des équipes en leur produit a augmenté, réduisant le stress et l'anxiété des employés travaillant dans un cadre maîtrisé et couvert par des tests
  • Quasiment zéro tests manuels sont effectués

J'irai même plus loin que ça, en disant que dans mon expérience, BDD permet de complètement retiré l'équipe de recettage à la fin de la chaîne en temps que testeurs QA.
Ils interviennent essentiellement lors de la phase de réalisation des scénarios.

Rappel sur son ancêtre TDD

Test Driven Development : Vous devriez tous savoir ce que c'est mais rappelons le rapidement. 

Les règles :

  • Première : Vous ne devez pas écrire de code projet tant que vous n’avez pas écrit un test unitaire d’échec.
  • Deuxième : Vous devez uniquement écrire le test unitaire suffisant pour échouer, l’impossibilité de compiler est un échec.
  • Troisième : Vous devez uniquement écrire le code projet suffisant pour réussir le test actuellement en échec (et faire passer les précédents)

Rappel sur les tests d'acceptation

Test d'acceptation : Réalisation d'un test visant à vérifier la conformité d'un produit par rapport aux spécifications définies.

Pendant très longtemps, ces tests étaient réalisées manuellement, soit par l'équipe de développement, soit par une équipe de recettage.

Automatisation :

  • L'automatisation de ses tests est réalisé grâce à des outils permettant de gérer un navigateur. On appelle cela un Driver.
  • Avec ces tests, on peut réaliser exactement ce que l'utilisateur va réaliser sur son interface
  • On doit tester les scénarios utilisateurs d'échec ou de réussite
  • Des indicateurs (reporting) peuvent être générés,...

Des users stories au scénarios

Comme on l'a rapidement évoqué, le Behavior Driven Development a vu le jour afin de pouvoir directement démarrer des users stories utilisées en méthodes agiles afin de réaliser nos tests d'acceptation directement en tests d'interface, ou en tests unitaires.

User story: 
As a visitor
I want to Login
So I can access to profil page

Acceptance Criteria : 
Given visitor fill username and password
When visitor click on login button
Then user is connected and is on profil page
Feature : Login

Scenario : Login and go to profil page
 Given visitor fill username and password
 When visitor click on login button
 Then user is connected and is on profil page

User story

Scenario

Feuille de route des exercices

WS_guidé : Partie 1

WS_simple_BDD

WS_guidé :

Partie 2

Comment allons-nous procéder ?

Cette formation contient peu de théorie, mais beaucoup de pratique. Après avoir analysé ensemble un exemple complet, nous allons réaliser plusieurs workshops.

ATDD

BDD Calculator

BDD

WS_noté :

BDD complète

Tests d'interface avec Selenium

Les tests d'interfaces

avec Selenium

Les tests d'interface

Pour simplifier la formation vu sa durée assez courte, je préfère vous montrer et vous faire réaliser des tests d'interface classique, sans la partie architecturale qui n'apporte pas grand chose à la formation.

 

Je vous montrerai et vous expliquerai l'utilité de la partie ATDD et je vous fournirai directement les sources pour que vous puissiez l'exploiter (son but étant surtout d'avoir des helpers qui enveloppent la partie Selenium tout en la testant)

Les tests d'interface

Les tests d'interface vérifient que les développements sont cohérents et fonctionnent sur toutes les plateformes cibles (par exemple, dans le web on vérifie chaque navigateurs)

A savoir :

  • Systématique pour chaque projet ! (Au moins de manière implicite / manuelle par le développeur ou équipe de recettage)
  • S'informer sur les plateformes cibles potentielles est important ici
  • Il est aussi possible de les automatiser (Selenium) en paramétrant notre test avec les plateformes cibles et les vérifications sur ces plateformes.
  • Framework .Net
  • Met a disposition des classes de getsion d'interface
  • Permet de démarrer et interagir avec un navigateur grâce à un Driver

Sélénium

Selenium est un framework qui va nous permettre de réaliser nos tests d'interface, il permet par exemple d'ouvrir le navigateur, accéder à une URL, vérifier la présence d'un élément, cliquer sur un boutton, remplir un input,...

Sélénium IWebElement
L'interface IWebElement

Une classe des plus utilisé de Selenium est IWebElement, elle permet de réaliser plusieurs opérations sur notre navigateur, ainsi que d'utiliser les éléments qu'elle permet d'identifier.

 

Les méthodes à connaître sont : FindElement(), FindElements(), Navigate(), Close(), Quit().
 

Sur un élément récupéré, vous avez des méthodes telles que Click(), SendKeys(), ... 

Sélénium Locator
La classe By

La class By va nous permettre d'identifier de plusieurs façons nos éléments d'interface.

  • By.Id() : Par l'id de l'élément
  • By.ClassName() : Par nom de classe de l'élément
  • By.LinkText() : Par un contenu de lien
  • By.CssSelector() : Par selecteur css
  • By.Name() : Par nom de l'élément
  • By.TagName() : Par html tag
  • By.XPath() : Par expression XPath

 

Honnêtement, nous n'allons quasiment qu'utiliser du By.Id() dans cette formation, mais il peut être intéressant pour vous de voir les expressions XPath.

Sélénium

Les packages Nuget

Pour utiliser Selenium, il nous faudra ajouter deux packages Nuget au projet :

  • Selenium.WebDriver
  • Selenium.WebDriver.GeckoDriver

GeckoDriver est le driver pour Firefox, il est le plus simple des driver à utiliser car il n'y a pas de soucis de version exacte à matcher.

 

  • Chrome : Selenium.WebDriver.ChromeDriver
  • IE : Selenium.WebDriver.IEDriver
  • Edge : Selenium.WebDriver.MSEdgeDriver
  • Safari (pas de package requis) : safaridriver --enable

Sélénium

Créer un WebDriver

La première étape est assez simple, il nous faut créer le WebDriver. Pour l'instant et pour cette étape, vous pouvez faire ça directement depuis votre Program.cs

using OpenQA.Selenium;
using OpenQA.Selenium.Firefox;

IWebDriver driver = new FirefoxDriver(); // Ou new ChromeDriver() ou new SafariDriver(),...

Accéder à une page

driver.Navigate().GoToUrl("https://example.com");

Sélénium

Vérifier la présence d'un élément

Maintenant, nous pouvons utiliser le Driver pour réaliser différentes opérations relatives à notre interface.

IWebElement element = driver.FindElement(By.Id("my-element-id"));

if (element != null)
    Console.WriteLine("L'élément est présent !");
else
    Console.WriteLine("L'élément est introuvable.");

Cliquer sur un bouton

IWebElement button = driver.FindElement(By.Id("my-element-id"));
button.Click();

Remplir un input

IWebElement input = driver.FindElement(By.Id("my-element-id"));
input.Clear(); // optionnel, ça clear juste l'input
input.SendKeys("Valeur que je veux mettre dans mon input");

Exercice Tests d'interface

Tester une interface pour remplir des numéros de cartes bancaire

  • Je vais vous donner une interface simple
     
  • Vous avez un docker-compose pour lancer l'interface (docker-compose up puis go sur http://localhost/Workshop.html)
     
  • Et un workshop assez guidé pour réaliser les différents tests d'interface sur cette petite interface

N'hésitez pas à me demander de l'aide

Acceptance Test Driven Development

(et autres prérequis)

 Les tests d'acceptation que nous allons réaliser sont des scénarios définis par des étapes qui doivent être respectées pour réaliser une opération sur un logiciel.
Ces tests peuvent être et sont très généralement des tests d'interface.

Nous allons voir comment réaliser ces tests d'acceptation sous forme de tests d'interface.
ATDD est souvent associé au BDD et en est l'initiateur, c'est pourquoi nous allons commencer par réaliser une ATDD avant de faire une BDD

C'est un TDD, mais avec notre interface, en gros.
L'objectif est de réaliser des tests d'interface automatisés sur l'intégralité de notre code.

Introduction - ATDD

  • Framework .Net
  • Met a disposition des classes de getsion d'interface
  • Permet de démarrer et interagir avec un navigateur grâce à un Driver

Démo ATDD

Pour vous montrer le concept d'ATDD, je vais vous présenter un projet de tests d'interface sur l'outil bWAPP.

Nous allons devoir réaliser plusieurs étapes pour y arriver. Vous devrez ensuite réaliser toutes ces étapes en suivant le workshop guidé (sur le jeu du serpent).
 

Voici un schéma du projet d'exemple  (réutilisable en partie pour d'autres projets) de mise en place d'une ATDD sur bWAPP.

Démo Schéma explicatif

ATDD (Tests)

1. Config

Contient les configurations nécessaires du projet

1. Config

Contient les configurations nécessaires du projet

1. Config

Contient les configurations nécessaires du projet

2. Base Class

Démarre et configure le WebDriver gérant notre navigateur

1. Config

Contient les configurations nécessaires du projet

3. Helper

Helper de gestion des composants Web

Contient les tests que l'on réalise pour l'intégralité du projet

MSTest est un framework de tests que l'on va utiliser tout au long de notre formation. 

 

Les choses à savoir :

  • Le test se fait sur une classe tout à fait normale
  • Il suffit de mettre les attributs [TestClass] au dessus de la classe
  • Et [TestMethod] au dessus de chaque méthode qui sera considérée comme un test

MSTest - Rappel ?

MSTest est un framework de tests que l'on va utiliser tout au long de notre formation. Au cas où voici la liste des attributs MsTests :

  • [TestClass] : Attribut définissant une classe comme une classe de test 
  • [TestMethod] : Méthode de test traduit comme un test
  • [TestInitialize] : Méthode exécutée avant chaque TestMethod
  • [TestCleanup] : Méthode exécutée après chaque TestMethod
  • [ClassInitialize] : Méthode d'initialisation de classe
  • [ClassCleanup] : Méthode de destruction de classe
  • [AssemblyInitialize] : Méthode d'initialisation d'assemblie
  • [AssemblyCleanup] : Méthode de nettoyage de l'assemblie
  • [TestCategory("name")] : Catégorise un ou plusieurs tests
  • [Ignore] : Ignore un test

MSTest - Attributs

Il est également possible de réaliser des assertions, visant à vérifier qu'un contenu correspond à ce qui est attendu, quelque soit la comparaison effectuée.

Exemples : 

  • Assert.IsTrue(booleanValue);
  • Assert.AreEqual(a, b);
  • Assert.IsNull(element);
  • ...

MSTest - Assertions

Si besoin de plus d'informations sur la réalisation de tests MSTest, visitez :
https://docs.microsoft.com/fr-fr/dotnet/core/testing/unit-testing-with-mstest

MSTest - Documentation

Partie 1 : IConfig + ConfigReader + appsettings.json & CustomExceptions

Nous allons avoir besoin d'un fichier de configuration et de pouvoir en lire les propriétés

Ceci se fait en plusieurs étapes : 

  • Créer un fichier appsettings.json contenant les propriétés du projet
  • Créer une classe mappant ces propriétés
  • Créer des tests utilisant ConfigurationBuilder
  • Créer les tests génériques utilisant une future classe ConfigReader
  • Développez la classe ConfigReader pour rendre accessible aisément notre configuration
  • ConfigReader sera utilisé plus tard pour notre socle de tests

Sélénium IWebElement
L'interface IWebElement

Comme vu précédemment, elle permet de réaliser plusieurs opérations sur notre navigateur, ainsi que d'utiliser les éléments qu'elle permet d'identifier.

 

Les méthodes à connaître sont : FindElement(), FindElements(), Navigate(), Close(), Quit().
 

Sur un élément récupéré, vous avez des méthodes telles que Click(), SendKeys(), ... 

Sélénium Locator
La classe By

La class By va nous permettre d'identifier de plusieurs façons nos éléments d'interface.

  • By.Id() : Par l'id de l'élément
  • By.ClassName() : Par nom de classe de l'élément
  • By.LinkText() : Par un contenu de lien
  • By.CssSelector() : Par selecteur css
  • By.Name() : Par nom de l'élément
  • By.TagName() : Par html tag
  • By.XPath() : Par expression XPath

 

Honnêtement, nous n'allons quasiment qu'utiliser du By.Id() dans cette formation, mais il peut être intéressant pour vous de voir les expressions XPath.

Partie 2 : Mise en place de test des navigateurs & IWebDriver

La première chose à faire lors d'une ATDD est de tester le lancement de notre navigateur et l'arrivée sur l'url présente dans notre fichier de configuration. Nous allons avoir besoin de Selenium et des WebDriver pour démarrer le navigateur.

Ceci se fait en plusieurs étapes : 

  • Créer une classe de test utilisant votre ConfigReader et un IWebDriver driver = new ChromeDriver() par exemple
  • Installez et importez les paquets
  • Le but étant d'accéder à votre page web sur l'url donnée dans l'appsettings.json

IWebDriver propose plusieurs méthodes qui nous seront utiles : Navigate(), Close(), Quit(),... 

Ainsi que des propriétés : Url, Title,...

Partie 3 : BaseClass & ObjectRepository

Ce que l'on souhaite maintenant faire, c'est mettre en place notre base qui va nous permettre de toujours démarrer notre navigateur, sur la bonne url provenant du fichier de config (et en profiter pour se donner un accès simple au ConfigReader)

Ici, ça se fait en :

  • Créant une classe ObjectRepository, avec deux propriétés static IConfig Config & static IWebDriver Driver
  • Créant une classe BaseClass que l'on va toper avec l'attribut [AssemblyInitialize] afin que ce soit démarrer dès le démarrage du projet, c'est dans cette méthode que l'on initialise ObjectRepository.Config & ObjectRepository.Driver
  • Il contiendra les méthodes pour récupérer les Drivers pour chaque navigateur
  • Ainsi qu'une méthode [AssemblyCleanup] pour fermer le navigateur

Partie 4 : Handling WebElement & ComponentHelper

Maintenant, on veut pouvoir interagir avec les composants d'interface et en faire des ComponentHelper pour en faciliter l'utilisation. 

Ici, ça se fait en :

  • Réaliser les tests pour récupérer un élément utilisant ObjectRepository.Driver.FindElement(By Locator)
  • Réaliser un GenericHelper pour pouvoir récupérer
    un élément 
  • Faire de même pour vérifier l'existance d'un élément
  • Réaliser pour chaque composant (exemple TextBox)
    des tests permettant d'intéragir avec le composant, par exemple ObjectRepository.Driver.FindElement(By.Id("input1").SendKeys("string a mettre dans la TextBox");
  • Réaliser des Helper permettant de réaliser les interactions avec les composants ainsi que leurs tests

Locator : By

Vu dans une slide précedente

Workshop guidé

ATDD sur bWAPP

A vous de jouer !

Je vous propose un workshop complètement guidé pour réaliser de l'ATDD (que l'on complètera par du BDD dans la partie suivante).

Cette ATDD sera sur une interface de bWAPP qui est une application utilisée dans la sécurité

 

Ce workshop va être assez long, prenez bien le temps de comprendre et posez moi des questions ! Ne restez pas bloqué.

 

Partie 1 : Envoyer Guided_Workshop.md

docker run -d -p 80:80 hackersploit/bwapp-docker

Behavior Driven Development & principes associés 

Comportements, scénarios &

Langage Gherkin

BDD Définition 

Une méthodologie basée sur le comportement

On démarre des user stories pour créer des scénarios, ces derniers vont définir des étapes permettant de réaliser le scénario.
On établit donc un projet qui répond exactement à la demande du client selon la définition des scénarios utilisateurs.

Behavior Driven Development prends les principes du TDD et des méthodes agiles.

Les besoins utilisateurs sont traduits en code est sont directement testables.

Incluant un recettage automatisé en intégration continue.

Critères d'accepation

Explique ce qui défini qu'un système fonctionne correctement.

 

Ecris de manière à ce qu'ils soient toujours en Pass/Fail via une assertion.

Scénario

Définis les conditions des critères d'acceptations

 

Définis les étapes du scénario et les sorties voulues (que ce soit en terme de page accédée, en terme de résultat attendu par une étape, etc...)

 

Ici chaque étape n'est pas forcément une assertion

Critères d'acceptation VS Scenario

Les éléments d'un scénario

  • Concrètement un scénario correspond à la description d'une user story. Il a sa petite description aussi.
     
  • Chaque étape du scénario permet de définir ce scénario, ces étapes sont définies avec les mots clés suivants :
    • Given : L'ensemble des conditions initiales (user on page X)
    • When : Un évènement survient (user input)
    • Then : Une sortie ou plutôt condition d'acceptation est attendue (souvent avec une assertion via Assert)
    • And : Elément un peu complémentaire qui va juste compléter le mot clé précédent.

Gherkin - Qu'est-ce que c'est ? 

Structuration de nos scénarios dans une langue compréhensible par un client

C'est un langage spécifique au domaine qui décris les comportements attendus par notre logiciel. Attention, ça n'est que la partie qui en décris le comportement. Il peut être écrit dans n'importe quel langue (français, anglais,...).
Il agit également en tant que documentation de l'application.
On démarre toujours avec un fichier FeatureFile.

Exemple de FeatureFile

Exemple de génération Step Definition plus loin...

Gherkin - Qu'est-ce que c'est ? 

Structuration de nos scénarios dans une langue compréhensible par un client

Chaque étape d'un scénario fait office d'un test unique (pour ne pas dire unitaire et confondre avec le test unitaire classique).
Plusieurs mots clés possibles : Given, When, Then,...

Fichier FeatureFile complet

Exemple de génération Step Definition plus loin...

Gherkin - Qu'est-ce que c'est ? 

Vous avez la possibilité de passer des arguments à vos tests

Ces arguments vont vous permettre de réaliser des tests avec des paramètres / arguments particuliers pour vos StepDefinitions

Fichier FeatureFile exemple

Exemple de génération Step Definition plus loin...

Gherkin - Qu'est-ce que c'est ? 

Vous avez la possibilité de passer des arguments à vos tests

Ces arguments peuvent aussi être mis en place sous forme de tables pour passer plusieurs arguments et donc réaliser le scenario plusieurs fois en fonction du nombre de ligne de votre tableau exemples

Fichier FeatureFile exemple

Exemple de génération Step Definition plus loin...

Gherkin - Qu'est-ce que c'est ? 

Vous avez la possibilité de passer des tableaux à vos tests

Ces arguments peuvent aussi être mis en place sous forme de tables pour passer plusieurs arguments et donc réaliser la step avec un ensemble d'éléments différents.

Fichier FeatureFile exemple

Exemple de génération Step Definition plus loin...

SpecFlow - Génération des tests

En .Net, on va utiliser SpecFlow nous permettant de générer nos StepDefinitions découlant de notre fichier FeatureFile vu précédement.

Exemple simple

SpecFlow - Génération des tests

Passer des tableaux à ses tests StepDefinitions associées

Ici, l'objectif est donc d'exécuter les tests plusieurs fois avec plusieurs paramètres différents pour chaque exécution de tests.

Fichier Step Definition exemple

Particularité génération auto

SpecFlow - Génération des tests

Passer des tableaux à son étape

Le tableau permettra de boucler sur un ensemble d'éléments pour en tester leur cohérence (par exemple, une combobox pour choisir le département, puis pouvoir choisir les villes associées au département)

Fichier Step Definition exemple

Les concurrents de SpecFlow

Tout d'abord SpecFlow utilise Cucumber pour interpréter le Gherkin

Les autres outils pour faire du BDD :

  • SpecFlow pour le .Net, c'est celui qu'on va utiliser
  • Serenity (Open Source)
  • Jasmine (javascript)
  • minitest (small and fast)
  • JGiven (Java)
  • Cucumber (Gherkin !!)
  • ...

Cucumber

Cucumber est à la fois une automatisation des tests, des spécifications exécutables et de la documentation dite "vivante".

Cucumber

Comment fonctionne Cucumber concrètement ? On démarre de fichier Feature, on définit les scénarios, les étapes. Et ça nous génère les StepDefinitions, le code "behind", et automatise le tout.

Cucumber - Step Definitions

Comme vu précédemment, les fichier FeatureFile contiennent la définition des étapes en anglais. 

SpecFlow / Cucumber permet de générer le fichier StepDefinition définissant le contenu de nos steps et donc de nos tests

  • Framework utilisant Cucumber
  • Gestion du Gherkin
  • Mise en place des StepDefinitions automatisée
  • Tests d'acceptation simple et intégré au Framework

Démo BDD

Pour mieux appréhender le BDD, nous allons voir un exemple concret réalisé sur l'ATDD présentée lors d'une partie précédente de cette formation.

Exercice BDD

BDD Simple Calculator

  • Je vous donne un FeatureFile complet et vous devez réaliser la BDD associée.

     
  • Un workshop assez guidé doit vous être envoyé : Simple_BDD_Workshop.md

 

N'hésitez pas à me demander de l'aide

Workshop guidé

BDD sur le Jeu du Serpent

A vous de jouer !

Réalisez la seconde partie du Workshop, celle-ci devrait être bien plus simple et rapide que la précédente.

 

Il se peut que vous ayez quelques soucis de configuration, pas de panique normalement tout est expliqué dans le workshop.

Sinon, demandez de l'aide, n'hésitez pas !

 

ET réalisez un scénario complet de test du jeu jusqu'à la fin, à vous de trouver un moyen d'y arriver :)

Partie 2 : Utiliser Guided_Workshop.md

Aller plus loin dans la mise en place du BDD

Page Object Model

Un design pattern définissant une classe correspondante à chaque page de l'interface

Contient : 

  • Une région contenant les Web Elements (inputs, boutons, liens,...)

     
  • Une région contenant les actions (clickLogin,...)


     
  • Une région avec les Navigation possibles entre les pages

Page Object Model

Schéma rapide pour notre cas d'utilisation

PageBase classe
1. Constructeur initialisant la page

2. Actions & Navigations communes

HomePage
WebElements + Actions spécifiques + Navigations

LoginPage
WebElements + Actions spécifiques + Navigations

EnterBugPage
WebElements + Actions spécifiques + Navigations

Page Object Model

Pourquoi un POM ?

Par définition, le POM a pour but de simplifier la gestion de nos interfaces, les actions et interactions de pages,...


C'est pourquoi le Page Object Model est souvent associé à l'ATDD et par induction au Behavior Driven Development.

 

Il n'est pas difficile à mettre en place, juste très chronophage si l'on l'applique sur une grosse interface utilisateur.

L'image a effectivement aucun rapport...

BDD - What's next ?

Ce n'est pas prévu dans ce cours, mais c'est important je trouve.

Il reste deux choses qui me semblent importantes que l'on a pas vu :

  • Le reporting : Des outils et lignes de commandes permettent de réaliser un reporting complet de vos cas de tests provenant de votre BDD. Le reporting peut être intégré à Azure DevOps (anciennement TFS, outil de gestion des sources, des builds, etc...)
     
  • L'intégration continue : Intégration des tests dans le cycle d'intégration continue, juste après que notre CI (Continous Integration) ne fasse le build de notre projet, nous allons pouvoir greffer nos tests d'acceptations et donc l'intérêt de notre BDD est forcément appliqué avant d'être déployé en production.

Evaluation

Partie pratique

BON COURAGE !

(après c'est fini)

Evaluation mise en place d'un Behavior Driven Development


Mise en place d'une BDD pour validation d'un trio d'input simulant l'entrée d'une carte bancaire.

4 scénarios à développer :

  • Scénario 1 : Les 3 entrées (Card Number, Expiration Date, CVC) sont remplies et sont correctes
  • Scénario 2 : Un scénario par entrée incorrecte 

 

Vous devez développer une mini page web pour réaliser du BDD avec des tests d'acceptation comme vu lors de la première partie de ce cours. La mise en place d'un appsettings est en bonus.

Behavior Driven Development

By Cėdric Brasseur

Behavior Driven Development

Formation sur le Behavior Driven Development

  • 467

More from Cėdric Brasseur