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

Contact :yquenechdu@gmail.com

Blog :www.openagile.net

Remerciement :Erwan Le Gall lundi 21 novembre 11

lundi 21 novembre 11