Behavior driven Development

2 001 vues

Publié le

Présentation de la pratique de BDD (Behavior driven Development)

Publié dans : Technologie
1 commentaire
3 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
2 001
Sur SlideShare
0
Issues des intégrations
0
Intégrations
31
Actions
Partages
0
Téléchargements
72
Commentaires
1
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Behavior driven Development

  1. 1. Behavior Driven Development Yannick Quenec’hdu novembre 2011lundi 21 novembre 11
  2. 2. 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-machinelundi 21 novembre 11
  3. 3. IL ÉTAIT UNE FOIS... Je n’ai rien Tu devrais à dire sur le en parler sur sujet ton blog les tests fonctionnelslundi 21 novembre 11
  4. 4. Les différents tests fonctionnels Approche centrée sur l’IHM Spécifications exécutables Behavior Driven Develpmentlundi 21 novembre 11
  5. 5. Approche centrée sur l’IHM Ceux qui pilotent un navigateur et reproduisent les interactions de l’utilisateur. IHM Outil de TF d’IHM Navigateur Applicationlundi 21 novembre 11
  6. 6. Approche centrée sur l’IHM Il existe aussi des outils, de type robots HTTP, qui eux se substituent au navigateur IHM Outil de TF d’IHM Applicationlundi 21 novembre 11
  7. 7. Approche centrée sur l’IHM Avantage Le test fonctionnel d’IHM permet de reproduire en intégralité les scénarios d’une application (vue de l’utilisateur)lundi 21 novembre 11
  8. 8. Approche centrée sur l’IHM Inconvénients Les 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 applicationslundi 21 novembre 11
  9. 9. Outils test IHM Selenium - Licence OpenSource Selenium est un ensemble de différents outils pour lautomatisation 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 navigateurslundi 21 novembre 11
  10. 10. Spécifications exécutables Une autre approche est celle des spécifications exécutables Outil de Fixtures spécifications Application exécutables Permet à des utilisateurs fonctionnels de décrire au sein d’un wiki le comportement métierlundi 21 novembre 11
  11. 11. Spécifications exécutables On remarque que lIHM nest pas testée. Une couche de fixture sy 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écutableslundi 21 novembre 11
  12. 12. Spécifications exécutables Il est possible de compléter l’outil en l’intégrant avec des tests de l’IHM. Outil de Fixtures IHM spécifications Outil de TF d’IHM Application exécutableslundi 21 novembre 11
  13. 13. La réalitélundi 21 novembre 11
  14. 14. 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 statiqueslundi 21 novembre 11
  15. 15. 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 ATDDlundi 21 novembre 11
  16. 16. 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
  17. 17. Les tests BDDlundi 21 novembre 11
  18. 18. Les tests avec 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’acceptationlundi 21 novembre 11
  19. 19. User stories 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”lundi 21 novembre 11
  20. 20. ATDD 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)lundi 21 novembre 11
  21. 21. Exemple “En tant qu’utilisateur, je veux me connecter à Google afin d’accéder à tous mes services en lignes” 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 disponibleslundi 21 novembre 11
  22. 22. Les critères d’acceptation Un critère d’acceptation doit être : Une vision utilisateur Ne pas proposer de solution Ne pas être interne à la fonctionlundi 21 novembre 11
  23. 23. BDD 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.lundi 21 novembre 11
  24. 24. 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énementslundi 21 novembre 11
  25. 25. 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 storieslundi 21 novembre 11
  26. 26. 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
  27. 27. 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 produitlundi 21 novembre 11
  28. 28. Avantage 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’équipelundi 21 novembre 11
  29. 29. Résultat 10% du temps projet consacré au BDD engendre 30% de déchets en moins durant le cycle de vie du projet BDD c’est LEANlundi 21 novembre 11
  30. 30. BDD en actionlundi 21 novembre 11
  31. 31. Une user stories à un comportement “En tant qu’utilisa teur anonyme, je connecter sur le veux me site afin daccéder aux informations de mon compte“lundi 21 novembre 11
  32. 32. Les critères d’acceptations 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 incorrectelundi 21 novembre 11
  33. 33. Résultat 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 ?lundi 21 novembre 11
  34. 34. BDD permet de raconter une histoirelundi 21 novembre 11
  35. 35. 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ésultatslundi 21 novembre 11
  36. 36. “Scénario compte valide” É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 pagelundi 21 novembre 11
  37. 37. “Scénario compte invalide” É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”lundi 21 novembre 11
  38. 38. Dinosaure Le cycle de vie BDDlundi 21 novembre 11
  39. 39. Les acteurs Le testeur Le PO Développeurslundi 21 novembre 11
  40. 40. Le client exprime son besoinlundi 21 novembre 11
  41. 41. Durant un atelier client....lundi 21 novembre 11
  42. 42. Le Product Owner traduit ce besoin User stories et critères d’acceptationlundi 21 novembre 11
  43. 43. Le testeur rédige les tests en BDD...lundi 21 novembre 11
  44. 44. avec les développeurs et le POlundi 21 novembre 11
  45. 45. les développeurs intègrent les tests Scénario BDD test BDDlundi 21 novembre 11
  46. 46. le testeur réalise les tests BDDlundi 21 novembre 11
  47. 47. et obtiens le résultatlundi 21 novembre 11
  48. 48. Conclusionlundi 21 novembre 11
  49. 49. Un produit sans testlundi 21 novembre 11
  50. 50. Un produit avec des testslundi 21 novembre 11
  51. 51. Blog : www.openagile.net Contact : yquenechdu@gmail.com Remerciement :Erwan Le Galllundi 21 novembre 11
  52. 52. lundi 21 novembre 11

×