Agile Tour Nantes 2011 - Arnaud Bailly et Jonathan Perret - spécification par l'exemple
4
Spécification par l'exemple Spécification par l'exemple Arnaud Bailly Jonathan Perret 13 octobre 2011 Plan 15': Principes des "tests d'acceptation" Agile 30': Exercice de Spécification par l'exemple 15': Conclusion & perspectives TDD Pratique centrale de XP, test unitaire, "Test First development" Tests orientés technologie qui soutiennent l'équipe Idée fausse: TDD est une technique pour créer des tests de regression TDD est un outil pour guider le développement vers une "Conception Simple" BDD BDD is a secondgeneration, outsidein, pull based, multiplestakeholder, multiplescale, highautomation, agile methodology. Dan North, cité par Gojko Adzic "TDD done right" ? Remonter le niveau d'abstraction des "tests" à celui des "User Stories": Le "Quoi faire?" plutôt que le "Comment faire?" Définition fluctuante et changeante, souvent liée à des outils: jBehave, RSpec, jDave... et plutôt un changement de perspective sur les tests unitaires ATDD Acceptance TestDriven Development ou Développement Dirigé par les Tests de Recette Mise en place AAFTT Workshop à partir d'Agile 2008 Comment intégrer la pratique du test et les testeurs dans les équipes Agile ? Que deviennent les spécifications dans les projets Agile ? La Recette est un terme contractuel or l'Agilité promeut la collaboration sur le contrat : quid des "Tests de recette" ? Les quadrants de Marick
description
Les méthodes agiles, du moins celles qui s'intéressent au contenu du logiciel produit plus qu'à l'organisation de ceux qui le produisent, insistent toutes sur l'importance des tests automatisés, et ce à tous les niveaux de granularité: test unitaires, d'intégration, fonctionnels, systèmes, "smoke tests", d'interface... Mais on automatise les tests depuis que l'on écrit du code.La vraie révolution introduite initialement par eXtreme Programming, qui reste la référence sur les pratiques concrètes d'ingénierie du logiciel, sur le travail au quotidien du développeur, a été de renverser la perspective : ce n'est plus le code qui définit quoi tester, ce sont les tests qui disent quoi coder. Ce saut conceptuel, ce renversement à la dimension quasi-copernicienne de la perspective du travail de développement, a eu un impact profond sur le métier de développeur - coder la réponse la plus simple à la question posée, pas plus, pas moins - mais aussi sur le métier de testeur - aider les développeurs au plus tôt et critiquer le produit, plutôt que gérer des montagnes de scripts.Aujourd'hui, c'est sous diverses appellations que le TDD étend sa sphère d'influence au delà du code, vers le domaine autrefois réservé du fonctionnel, le royaume des analystes, des consultants, des QA : Acceptance TDD, Spécification par l'exemple, Spécifications Exécutables ou encore Behaviour Driven Development sont quelques uns des néologismes forgés pour désigner l'activité spécifique consistant à ne pas écrire de code avant que d'avoir défini précisément, au moyen d'un testexécutable, les contours de la fonctionnalité attendue.Au delà des outils, cette session propose de construire des réponses, évidemment partielles, pas nécessairement définitives et certainement pas dogmatiques, aux questions suivantes: pourquoi est-il important de mettre en place une démarche de Spécification par l'exemple ? Quels en sont les bénéfices pour le logiciel ? Comment cela s'articule-t'il avec d'autres tests (régression, smoke, unitaires, d'intégration) ? D'autres pratiques d'assurance qualité ? Le processus de développement ? Comment ne pas (trop) se tromper lorsqu'on veut mettre en place une telle démarche ? Comment sont définis, réalisés, exécutés et maintenus ces tests ? Comment ces tests sont-ils liés aux autres pratiques agiles, et en particulier à la définition des "User stories" ?
Transcript of Agile Tour Nantes 2011 - Arnaud Bailly et Jonathan Perret - spécification par l'exemple
Spécification par l'exemple
Spécification par l'exempleArnaud Bailly Jonathan Perret13 octobre 2011
Plan15': Principes des "tests d'acceptation" Agile30': Exercice de Spécification par l'exemple15': Conclusion & perspectives
TDDPratique centrale de XP, test unitaire, "Test First development"Tests orientés technologie qui soutiennent l'équipeIdée fausse: TDD est une technique pour créer des tests de regressionTDD est un outil pour guider le développement vers une "Conception Simple"
BDDBDD is a secondgeneration, outsidein, pull based, multiplestakeholder, multiplescale, highautomation, agilemethodology.
Dan North, cité par Gojko Adzic
"TDD done right" ?Remonter le niveau d'abstraction des "tests" à celui des "User Stories": Le "Quoi faire?" plutôt que le "Commentfaire?"Définition fluctuante et changeante, souvent liée à des outils: jBehave, RSpec, jDave... et plutôt un changement deperspective sur les tests unitaires
ATDDAcceptance TestDriven Development ou Développement Dirigé par les Tests de RecetteMise en place AAFTT Workshop à partir d'Agile 2008Comment intégrer la pratique du test et les testeurs dans les équipes Agile ?Que deviennent les spécifications dans les projets Agile ?La Recette est un terme contractuel or l'Agilité promeut la collaboration sur le contrat : quid des "Tests de recette" ?
Les quadrants de Marick
Des tests orientémétier pour soutenir l'équipeTests définis du point de vue de l'usage du produit, des utilisateursExpliciter les besoins avant de développer : quelle est la fonctionalité que l'on souhaite produire ?Construire une suite de tests de nonrégression pour vérifier que des développements futurs ne cassent rien
Collaborer pour…Développer le bon logiciel, celui qui est attendu par les utilisateursNe pas développer des fonctionnalités inutilesNe pas accumuler de dette technique et maintenir l'existant
Formaliser les spécifications ?Approche pilotage par les modèlesTravailler à un niveau d'abstraction plus élevé mais plus compréhensible pour les utilisateursAutomatiser le processus de réalisation du système à partir des modèles pour garantir la cohérenceMais modéliser, c'est déjà coder : on ne peut pas automatiquement produire une information qui n'est pas déjà dans lemodèle
Les problèmes que l'on cherche à résoudre
La Spécification par l'exemple"Pour établir une pratique, les règles ne suffisent pas; on a également besoin d'exemples"
L.Wittgenstein, De la certitude, 1969
La Spécification par l'exempleATDD Done Right !Grandement inspiré par les travaux de Gojko Adzic et d'autres dans la communauté du Test Agile (Lisa Crispin, JanetGregory, Brian Marick...)On parlera aussi de Spécification Exécutable, mais…une spécification est ellemême un encodage du problème considéréon ne parle ici que d'exemples, ç.à.d. un échantillonage de l'espace du problème/des solutionsterme plutôt en faveur pour des spécifications formelles
Définir le "Quoi?"Spécification de "stories" pardelà le postitUne "story" devrait être une opportunité de conversation, mais comment savoir quand nous avons fini ?Les exemples soutiennent la conversation, offrent des points d'appui pour étudier de nouvelles perspectives
Écrire les exemplesProposition: Utiliser des formes contraintes pour décrire les spécifications1 story = But/Rôle/ActionAfin d'atteindre un certain but un Utilisateur Veut réaliser une action1 exemple = Etant donné/Quand/AlorsEtant donné un certain état du système Quand l'utilisateur fait quelque chose Alors le système atteint tel étatNe pas confondre le quoi et le commentNe pas oublier le pourquoi
Exercice
C'est à vous de travailler !
Faire vivre le produitMais nous voulons construire un produit…Les "stories" représentent le chemin que nous suivons pour développer le logiciel : chaque "story" modifie le produitd'une façon spécifiqueMais le produit n'est pas la somme des "stories" : il n'est pas possible de reconstruire la séquence exacte de "stories"implémentées étant donné un état particulier du produit (sauf à consulter le système de gestion de versions, bien sûr)D'où la question : fautil garder tous les tests que nous écrivons pour implémenter les "stories" ?Et la réponse est : "Probablement non !"Les tests comme le code doivent être remaniés, évoluer avec le produit/système
Faire évoluer les tests1. Définir les tests de recette pour une "story" donnée avant le début du codage, les écrire comme ils viennent sous forme
exécutable2. Une fois la "story" finie, transformer les tests en exemples de spécification : les regrouper avec l'ensemble des tests pour
la fonctionnalité que cette "story" ajoute ou complète3. Utiliser le test exploratoire pour améliorer les spécifications du produit, et ce faisant créer de nouvelles "stories". En
particulier, les testeurs (et les développeurs bien sûr) sont habiles à trouver des cas extrêmes, des chemins non couverts,des contradictions…
Mieux communiquerC'est donc que “suivre la règle” est une pratique. Croire que l'on suit la règle n'est pas la suivre. C'est donc aussiqu'on ne peut pas suivre la règle privatim ; sinon croire que l'on suit la règle serait la même chose que la suivre.
L.Wittgenstein, Recherches Philosophiques, §202, 1953
On cherche à construire une documentation vivante qui ne soit pas que le codeNoeud de communication entre les différents rôles de l'équipe (testeurs, experts métiers, développeurs, designers, entreautres)
RéférencesGojko Adzic, Specification By Example, Manning 2011Gojko Adzic, Bridging the Communication Gap, Neuri 2009L.Crispin & J.Gregory, Agile Testing, AddisonWesley, 2009
