Upload
yannick-quenechdu
View
1.391
Download
0
Embed Size (px)
DESCRIPTION
Présentation de la pratique de BDD (Behavior driven Development)
Citation preview
Behavior Driven Development
Yannick Quenec’hdunovembre 2011
lundi 21 novembre 11
Les types de tests
Les tests structurels (TDD aussi appelé test des boîtes blanches)
Les tests fonctionnels (ATTD aussi appelé test des boîtes noires)
Les tests d’interfaces, ce sont les tests de l’interface homme-machine
lundi 21 novembre 11
IL ÉTAIT UNE FOIS...
les tests fonctionnels
Je n’ai rien à dire sur le
sujet
Tu devrais en parler sur
ton blog
lundi 21 novembre 11
Les différents tests fonctionnels
Approche centrée sur l’IHMSpécifications exécutables
Behavior Driven Develpment
lundi 21 novembre 11
Approche centrée sur l’IHM
Ceux qui pilotent un navigateur et reproduisent les interactions de l’utilisateur.
Outil de TF d’IHM Navigateur ApplicationIHM
lundi 21 novembre 11
Il existe aussi des outils, de type robots HTTP, qui eux se substituent au navigateur
Outil de TF d’IHM ApplicationIHM
Approche centrée sur l’IHM
lundi 21 novembre 11
Avantage
Le test fonctionnel d’IHM permet de reproduire en intégralité les scénarios d’une application (vue de l’utilisateur)
Approche centrée sur l’IHM
lundi 21 novembre 11
InconvénientsLes tests sont décrits dans un formalisme technique.
Certains outils peuvent pallier à cette contrainte, mais on perd la démarche du développement piloté par les tests
Ces tests semblent exhaustifs, mais ne le sont pas.
Par exemple toute la partie batch des applications est exclue et de manière générale des pans entiers des applications
Approche centrée sur l’IHM
lundi 21 novembre 11
Outils test IHM
Selenium - Licence OpenSource
Selenium est un ensemble de différents outils pour l'automatisation des tests d’IHM
Watir - Licence OpenSource
Watir est un projet similaire à celui de Selenium, il permet d’enregistrer et de rejouer des tests avec différents navigateurs
lundi 21 novembre 11
Spécifications exécutables
Une autre approche est celle des spécifications exécutables
Outil de spécifications exécutables
Application
Fixt
ures
Permet à des utilisateurs fonctionnels de décrire au sein d’un wiki le comportement métier
lundi 21 novembre 11
On remarque que l'IHM n'est pas testée. Une couche de fixture s'y substitue.
Avantages
Le formalisme des spécifications est compréhensible par des populations fonctionnelles.
Il est possible, au sein même des tests, d’écrire de la documentation fonctionnelle dans un wiki.
Les pages de wiki sont des vraies spécifications exécutables
Spécifications exécutables
lundi 21 novembre 11
Spécifications exécutables
Il est possible de compléter l’outil en l’intégrant avec des tests de l’IHM.
Outil de TF d’IHM ApplicationIHM
Outil de spécifications exécutables Fi
xtur
es
lundi 21 novembre 11
La réalité
lundi 21 novembre 11
Spécifications exécutables
Inconvénients
Un coût important de mise en oeuvre en terme de formation aux outils et d’intégration des fixtures
La sémantique du wiki est très spécifique aux outils (tables de décision, query, etc)
Un wiki qui mélange les noms de classe, méthode et texte statiques
lundi 21 novembre 11
Behavior Driven Devlopment C’est une pratique qui encourage la collaboration entre
les développeurs, les testeurs et le Product Owner
BDD est un langage naturel qui en met en avant les interactions du logiciel
Il limite la traduction entre le langage technique (développeurs) et le langage métier (l’entreprise)
Permet d’automatiser les tests unitaires et de non-régression
Il se situe entre TDD et ATDD
lundi 21 novembre 11
Outils de BDD
Plus d’une trentaine d’outils en OpenSource pour l’ensemble des
langages informatique (Java, PHP, Ruby, Net, Javascript, etc.)
lundi 21 novembre 11
Les tests BDD
lundi 21 novembre 11
Les tests user stories sont formalisés de manière à ajouter des critères d’acceptation
BDD permet d’enrichir les user stories en proposant des spécifications du comportement
de la user stories
Ce ne sont pas des critères d’acceptation
Les tests avec BDD
lundi 21 novembre 11
Une user story est une façon de “spécifier” un besoin fonctionnel. C’est une surtout une
méthode de communication au sein d’une équipe Agile
Une user story est exprimée selon la matrice rôle / fonction
En tant que “rôle”, je veux “faire une action”, afin d’ “atteindre un objectif”
User stories
lundi 21 novembre 11
L’approche ATDD ou Acceptance Test Driven Development implique de préciser le besoin
par la définition des critères de contrôles (d’acceptation)
ATDD
lundi 21 novembre 11
Imaginons les critères suivants :• L’utilisateur peut se connecter• La barre de menu Google présente les services disponibles
• L’utilisateur peut accéder à tous ces services• Google présente la liste des nouvelles fonctionnalités disponibles
“En tant qu’utilisateur, je veux me connecter à Google afin d’accéder à tous mes services en lignes”
Exemple
lundi 21 novembre 11
Un critère d’acceptation doit être :
Une vision utilisateur Ne pas proposer de solution
Ne pas être interne à la fonction
Les critères d’acceptation
lundi 21 novembre 11
le langage Gherkin défini pour le BDD ou Behavior Driven Developement
Aussi connu dans le monde Agile sous la pratique de Given / When / Then (And).
Cette méthode est aussi appelée TDR pour Test Driven Requirement ou exigences pilotées par les tests.
BDD
lundi 21 novembre 11
BDD est bien plus qu’une pratique de test, c’est une évolution dans la rédaction des Users stories
En tant que testeurs vous êtes limité dans les tests des users stories, parce qu’il n’y a pas de contexte, de règle métier ou séquences d’événements
BDD
lundi 21 novembre 11
Une user stories “Je suis... Je veux... Afin de...” laisse la place à des interprétations erronées
La cause et l’effet ne sont pas décrits dans les users stories
lundi 21 novembre 11
Contrairement aux users stories, le “comportement” suggéré par le BDD apporte
le contexte (Etant donné que), l’événement (Lorsque), et le résultat
(Alors)
lundi 21 novembre 11
Le contexte, l’événement et le résultat sont identifiés pour chaque action de l’utilisateur ou
du système
BDD fonctionne comme une spécification pour le comportement
du produit
lundi 21 novembre 11
Permet aux développeurs et aux testeurs de comprendre les actions à réaliser et comment le système va répondre
Réduit les ambiguïtés dans les users stories
Fournit des spécifications simples et réduis les aller-retour sur les users stories
BDD permet de se poser les bonnes questions durant l’analyse de la user stories
L’activité de réflexion est mieux répartie au sein de l’équipe
Avantage
lundi 21 novembre 11
10% du temps projet consacré au BDD engendre 30% de déchets en moins durant le
cycle de vie du projet
BDD c’est LEAN
Résultat
lundi 21 novembre 11
BDD en action
lundi 21 novembre 11
Une user stories à un comportement
“En tant qu’utilisateur anonyme, je veux me connecter sur le site afin d'accéder aux informations de mon compte“
lundi 21 novembre 11
La page d’accueil doit afficher une boîte de connexion
Le système doit valider les identifiants et les mots de passe
L’identifiant doit être au format email
Le mot de passe doit être avec un minimum de 6 caractères et 1chiffre
Le système doit afficher le tableau de bord si l’authentification est valide
Le système doit afficher une erreur en cas d’authentification incorrecte
Les critères d’acceptations
lundi 21 novembre 11
Le testeur indique vrai ou faux, le résultat des tests d’acceptation
Aucune description des événements, ni des actions de l’utilisateur
La cause et l’effet sont absents
Où est l’histoire derrière la user stories ?
Résultat
lundi 21 novembre 11
BDD permet de raconter une histoire
lundi 21 novembre 11
La matrice GWT
La matrice Given - When - then est le format utilisé pour la rédaction en BDD
Given (Etant donné que) : Le contexte
When (Lorsque) : L’action
Then (Alors) : Le résultat
And (Et) : Les autres résultats
lundi 21 novembre 11
Étant donnée que je suis un utilisateur anonyme qui sait précédemment enregistrer et qui se trouve sur l’espace de connexion de la page d’accueil
Lorsque l’utilisateur saisit son identifiant et son mot de passe dans la boîte de connexion et clique sur le bouton “connexion” ou frappe sur la touche “Entrer”
Alors le système doit valider le nom de l’utilisateur et le mot de passe et rediriger l’utilisateur vers le tableau de bord si le compte est valide
Et il devra afficher l’identifiant de l’utilisateur en haut de la page
Et il devra actualiser la date de dernière connexion de l’utilisateur sur la page
“Scénario compte valide”
lundi 21 novembre 11
Étant donné que je suis un utilisateur anonyme qui sait précédemment enregistré et qui se trouve sur l’espace de connexion de la page d’accueil
Lorsque l’utilisateur saisi son identifiant et son mot de passe dans la boîte de connexion et clique sur le bouton “connexion” ou frappe sur la touche “Entrer”
Alors le système doit valider le nom de l’utilisateur et le mot de passe
et si l’identifiant est invalide il doit afficher un message d’erreur sur la page d’accueil “Identifiant invalide”
et si le mot de passe est invalide il doit afficher un message d’erreur sur la page d’accueil “mot de passe invalide”
“Scénario compte invalide”
lundi 21 novembre 11
Le cycle de vie BDD
Dinosaure
lundi 21 novembre 11
Les acteurs
Le PO
Le testeur
Développeurslundi 21 novembre 11
Le client exprime son besoin
lundi 21 novembre 11
Durant un atelier client....
lundi 21 novembre 11
Le Product Owner traduit ce besoin
User stories et critères
d’acceptation
lundi 21 novembre 11
Le testeur rédige les tests en BDD...
lundi 21 novembre 11
avec les développeurs et le PO
lundi 21 novembre 11
les développeurs intègrent les tests
Scénario BDD
test BDD
lundi 21 novembre 11
le testeur réalise les tests BDD
lundi 21 novembre 11
et obtiens le résultat
lundi 21 novembre 11
Conclusionlundi 21 novembre 11
Un produit sans test
lundi 21 novembre 11
Un produit avec des tests
lundi 21 novembre 11
lundi 21 novembre 11