Behavior driven Development

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


IL ÉTAIT UNE FOIS...

les tests fonctionnels

Je n’ai rien à dire sur le

sujet

Tu devrais en parler sur

ton blog


Les différents tests fonctionnels

Approche centrée sur l’IHMSpécifications exécutables

Behavior Driven Develpment


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


Il existe aussi des outils, de type robots HTTP, qui eux se substituent au navigateur

Outil de TF d’IHM ApplicationIHM



Avantage

Le test fonctionnel d’IHM permet de reproduire en intégralité les scénarios d’une application (vue de l’utilisateur)



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



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


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


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




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


La réalité



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


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


Outils de BDD

Plus d’une trentaine d’outils en OpenSource pour l’ensemble des

langages informatique (Java, PHP, Ruby, Net, Javascript, etc.)


Les tests BDD


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


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


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


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


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


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


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


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


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)


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


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


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


BDD en action


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“


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


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


BDD permet de raconter une histoire


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


É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”


É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”


Le cycle de vie BDD

Dinosaure


Les acteurs

Le PO

Le testeur

Développeurslundi 21 novembre 11

Le client exprime son besoin


Durant un atelier client....


Le Product Owner traduit ce besoin

User stories et critères

d’acceptation


Le testeur rédige les tests en BDD...


avec les développeurs et le PO


les développeurs intègrent les tests

Scénario BDD

test BDD


le testeur réalise les tests BDD


et obtiens le résultat


Conclusionlundi 21 novembre 11

Un produit sans test


Un produit avec des tests


Contact :[email protected]

Blog :www.openagile.net

Remerciement :Erwan Le Gall lundi 21 novembre 11

mailto:[email protected]


http://www.openagile.net

http://www.openagile.net



Behavior driven Development

Technology

Transcript of Behavior driven Development