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
