Introduction aux spécifications exécutables (dit aussi atdd, bdd)
•
8 likes•1,937 views
Comment s'assurer que tout le monde parle la même langue dans l'équipe ? Et ainsi éviter les retours de recette ? Utiliser des spécifications exécutables, ou ses cousins le ATDD (Acceptance Test Driven Development) et le BDD (Behavior Driven Development), est un élément de réponse particulièrement pertinent. Cette méthode est également un point d'entrée puissant vers une stratégie d'automatisation des tests. Dans cette présentation vous découvrirez les tenants et les aboutissants de cette méthode, et repartirez les poches remplies de conseils de mise en place.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Similar to Introduction aux spécifications exécutables (dit aussi atdd, bdd) (20)
More from Jean-Pierre Lambert
More from Jean-Pierre Lambert (18)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
- 2. Qu’est-ce que la qualité ? Réponse à plusieurs dimensions
- 3. Besoins d’accomplissement de soi Besoins d’estime Besoins d’appartenance et d’amour Besoins de sécurité Besoins physiologiques Pyramide des besoins de Maslow
- 4. Besoins d’accomplissement de soi Besoins d’estime Besoins d’appartenance et d’amour Besoins de sécurité Besoins physiologiques Une vue partagée de la qualité Réussite Prospère Utile Intuitif Ergonomique Performant Sécurisé – Fiable Déployable FonctionnellementOK
- 5. Réussite Prospère Intuitif Ergonomique Utile Performant Sécurisé – Fiable Déployable FonctionnellementOK Une vue partagée de la qualité
- 6. • Comment aligner ces visions ? • En se parlant ! • Quelle méthode de facilitation ? • Les spécifications exécutables ! • Le moyen de s’assurer qu’on parle tous la même langue …? !
- 7. Spécifications exécutables ? Spec by Example, Behavior-Driven Development
- 8. Une documentation vivante Toujours à jour Versionnée comme le code Vérifiable à tout instant par rapport au code Utile pour toute l’équipe
- 9. À chaque test son outil !
- 13. Test Technique Test Fonctionnel Le test échoue : qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ?
- 14. Test Technique Test Fonctionnel Le test échoue : qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ?
- 15. Test Technique Test Fonctionnel Le test échoue : qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel
- 16. Test Technique Test Fonctionnel Le test échoue : qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel Outils spécifiques Outils génériques
- 17. Test Technique Test Fonctionnel Le test échoue : qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel Outils spécifiques Outils génériques
- 18. Test Technique Test Fonctionnel Le test échoue : qui sait dire pourquoi ? Régression ou changement fonctionnel ? Requirement Technique Requirement Fonctionnel ? Qui doit pouvoir comprendre ce test ? Langage : code Langage : pseudo- naturel Outils spécifiques Outils génériques Efficacité ! Lisibilité !
- 19. Pratiques à éviter Comment être sûr de ne pas y arriver
- 20. Ecueil 1 : Penser qu’un outil ou une méthode magique résoudra tous les problèmes ! But : 3 amigos ! Se parler, se parler, se parler… … Se comprendre ! …Travailler ensemble !
- 21. Ecueil 2 : Les dev rédigent les spécifications exécutables. But : avoir un document de référence compréhensible par les fonctionnels Que va-t-il se passer si ce sont les dev qui rédigent ? Bonne pratique (obligatoire) : rédaction par PO/MOA … Mais bien entendu avec relecture/en coopération avec les dev’ ! (cf. slide précédente)
- 22. Ecueil 3 : Ne pas investir dans l’outillage de test. But : avoir des tests tenus à jour et vérifiables à tout instant Appliquer les bonnes pratiques d’ingénierie ! Mettre en place une modélisation fonctionnelle, par exemple Page Object Model pour une appli web Sinon que va-t-il se passer ? Investir dans les outils : cher mais a-t-on le choix ? ©MartinFowler
- 23. Ecueil 4 : Focaliser uniquement ses efforts sur les tests de haut-niveau. But : réduire les régressions et maîtriser son produit Que va-t-il se passer si on néglige les tests bas niveau ? (unitaire + assemblage) Bonne pratique : tests haut-niveau pertinents si accompagnés d’une bonne couverture de tests unitaires et d’intégration dans tous les cas commencer par là !
- 24. Mise en pratique : Example Mapping Un atelier pour mettre en place la démarche
- 25. Example Map Blog de Cucumber – Example Mapping Introduction http://bit.ly/example-map
- 27. Exemple de mise en place : FitNesse De la spec JIRA jusqu’au code
- 29. Résumé de l’algorithme décrit par l’US : 1. Autoriser les tops manuels et ingestions (jobs de type manual et ingest) 2. Pour les tops automatiques: 1. Bloquer tout ce qui est interdit aux -16 et -18 2. Pour ce qui n'est pas -16/-18 : bloquer tout ce qui est Film, sauf s'il s'agit d'un Court métrage
- 30. Organisation de la base de test Factorisation préparation avant testSpec en langage naturel Les tests
- 35. Lien entre test et code métier Les tableaux sont des tests Métier : écriture des cas de test DEV : code de lien entre tests et code de prod
- 36. Données d’entrée des tests Lien entre test et code métier Chaque ligne est un test
- 37. Setup à partir des données du test Appel du code métier Lien entre test et code métier Chaque ligne est un test
- 38. Résultats attendus Lien entre test et code métier Chaque ligne est un test
- 39. Exemple d’écriture de test workflow : Robot Framework Et un de ses IDE, RIDE
- 40. Mise en pratique
- 41. Exemple « Given-When-Then » (Gherkin): Cucumber Ou selon votre plate-forme : Behat, SpecFlow…
- 43. Quel outil choisir ? Comparaison et recommandations Spoiler alert : par défaut, prenez Cucumber
- 45. TL;DR • Tous les outils peuvent tout faire • Cucumber est le plus facile d’accès pour les non-techniques, et disponible partout
- 46. • Un outil établi et connu • Installation triviale • Wiki intégré, format doc directement accessible • Runner disponible pour beaucoup de plate- formes • Les plus belles tables de décision • Un endroit où écrire du beau blabla • Un outil vieillot • Langage incohérent • Scénarii workflow imbitables • Concepts contre-intuitifs • Utilisation duWiki obligatoire, rapports de test et rédaction pas « text-friendly » • Pas d’éditeur avancé pour les non-dev
- 47. • Pas vraiment d’IDE qui s’adresse aux fonctionnels • La coloration syntaxique ne marche qu’en anglais • Langage restreint et contraignant • Plus (+) de code de lien • Multi-plate-forme au niveau source : Gherkin • Runner disponible sur quasiment tous les environnements, directement intégré • Prise en main simple, pas d’outil nécessaire à la rédaction • Des contraintes de rédaction qui en font un excellent outil pédagogique • Langage localisable en français • La référence dans le domaine : « Given-When- Then » est utilisé par tout le monde
- 48. • Langage très complet, puissant, régulier • Réutilisation des mots-clés, sans limite • Multi-plate-forme avec possibilité de mélanger les technos dans le même test • Nombreuses librairies clé-en-main, ajout en Python ou serveurs de mots-clés dynamiques dans n’importe quel langage • Nombreux outils associés, matures et complets • Plusieurs vrais IDE non restreints aux développeurs • Liberté du format de test : workflow, table de décision, Given-When-Then… • Langage complexe, difficile d’accès aux non- techniques • IDE parfois buggé, certains use-cases du langage non supportés sans édition textuelle • Serveurs de mots-clés pas disponibles sur tous les environnements
- 49. • Littéralement une spec qu’on peut exécuter • Belle intégration d’images et autres éléments de description d’une spec • Plate-formes majeures uniquement (Java, C#, Python, Ruby)
- 50. • Rédaction en MarkDown, écosystème MarkDown pour le formatage et l’édition • Par ! • Plein de bonnes idées, essaie de reprendre le meilleur de ses aînés • Java / C# / Ruby / JavaScript / Python / Golang • Relativement jeune
- 51. • Mettre le pied à l’étrier des fonctionnels • Dispo quelle que soit votre techno • Multi-techno au niveau de Gherkin • Enorme communauté • Beaucoup d’outils dérivés • La référence !
- 52. Les différents membres de l’équipe dans la démarche Et le testeur, il fait quoi dans tout ça ?
- 54. Comment démarrer ? Alors qu’on a déjà du code !
- 55. Let’s do it !
Editor's Notes
- Besoins physiologiques (faim, soif, sexualité, respiration, sommeil, élimination) Besoins de sécurité (environnement stable et prévisible, sans anxiété ni crise) Besoins d'appartenance et d'amour (affection des autres) Besoins d'estime (confiance et respect de soi, reconnaissance et appréciation des autres) Besoin d'accomplissement de soi
- Besoins physiologiques (faim, soif, sexualité, respiration, sommeil, élimination) Besoins de sécurité (environnement stable et prévisible, sans anxiété ni crise) Besoins d'appartenance et d'amour (affection des autres) Besoins d'estime (confiance et respect de soi, reconnaissance et appréciation des autres) Besoin d'accomplissement de soi
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- Spec exécutable : Une documentation vivante, Toujours à jour, Versionnée comme le code, Vérifiable à tout instant par rapport au code
- 1. Rédiger un test sur l’existant 2. Le faire marcher 3. Définir un process pour les nouveaux développements 4. Intégrer l’écriture des tests d’acceptation en amont du dev !