Dans le premier article, nous avons commencé à suivre une petite équipe de développement dans sa découverte de « l’Acceptance Test-Driven Development ». Nous avons quitté Héloïse, Aurore et Nicolas après une première phase de « spécification par l’exemple ». Nous les retrouvons dans le second article de cette série alors qu’ils s’apprêtent à démarrer l’implémentation de leur première User Story !
Automatisation des premiers tests d’acceptation
Le Sprint démarre donc, et la User Story « En tant que client de la pizzeria, je veux savoir combien va me coûter ma livraison de pizzas » est en bonne première place dans le Sprint Backlog. Aurore et Nicolas décident de travailler ensemble afin de continuer à expérimenter l’ATDD sur cette User Story.
Et oui, l’ATDD n’a pas la prétention de remplacer tous vos tests par des tests automatisés. Si l’on reprend les célèbres quadrants, on remarque que les tests que l’on a écrits ne concernent que la partie supérieure gauche !
En revanche, puisque l’ATDD cherche à rendre utilisable une partie au moins de la fonctionnalité beaucoup plus tôt qu’avec une approche plus traditionnelle du développement, elle permet de commencer à tester d’autres aspects bien plus tôt aussi.
C’est tout pour ce deuxième article de la série. Mais ne vous arrêtez surtout pas là ! Car, certains d’entre vous l’ont peut-être remarqué, Nicolas et Aurore ont commis de sérieuses erreurs dans leur première expérience avec l’ATDD. Dans le prochain article, nous verrons ce qui cloche exactement dans ce qu’ils ont fait, quelles conséquences cela a sur l’équipe à long terme, et apporterons des solutions.
A très vite !