tdd

Livre sur les tests avec JUnit

Samedi, le facteur m'a apporté un livre

Il s’agit de : JUnit, mise en œuvre pour automatiser les tests en Java. L’auteur du livre est Benoit Gantaume. J’avais fait sa connaissance l’an dernier lors de la conférence Agile France à Paris, nous nous étions retrouvés à la même table lors du repas. Benoit est facile à reconnaitre : c’est le seul qui porte un costume avec cravate dans les conférences sur l’agilité. Et comme il est grand, on ne peut pas le rater.

Les tests, un moyen d'améliorer la communication

Au lieu de test d'acceptation, spécification par l'exemple serait probablement plus approprié

Les tests d’acceptation (au sens agile) remplacent une spécification fonctionnelle détaillée. Avec un bénéfice essentiel : la communication est facilitée entre le métier et le développement. Vendredi dernier, à la conférence agile de Toulouse, il y avait un retour d’expérience sur les tests dans un projet agile. Il y a été question essentiellement des tests d’acceptation. Et de pilotage par les tests d’acceptation (ATDD). D’abord une précision : le terme acceptation ne doit pas être compris comme dans acceptance test ou UAT, phase à la fin d’un projet pour obtenir la signature du client, comme confirmation qu’il accepte le produit livré.
Pilotage par les tests d'acceptation

Pilotage par les tests d'acceptation

Méta-modèle

Après le TDD, voici l’ATDD. Dans l’épisode précédent, nous avions vu qu’une story était un élément du backlog de produit. Un principe, dans toutes les méthodes agiles, est qu’une story soit réalisée en une itération. Mais comment savoir si elle est vraiment finie à la fin de l’itération ? C’est la responsabilité du product owner d’accepter ou pas une story. Pour cela, le moins qu’il puisse faire est de définir ses conditions de satisfaction.

Exigences et tests, tests et exigences : un ruban de Möbius

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l’hypothèse d’une équivalence entre les tests et les exigences. L’article Tests and Requirements, Requirements and Tests: A Möbius strip, est signé de Grigori Melnik et de Robert C. Martin, le célèbre Uncle Bob. La référence au ruban de Möbius illustre comment les 2 disciplines (exigences et tests) en deviennent une seule lorsque le formalisme augmente.

Tests d'acceptation orientés comportement

Voire même Behaviour Driven Development

Un test, c’est une expérimentation menée pour révéler des informations, ou en réponse à une question précise sur un logiciel ou un système. Dans le cadre d’une approche agile basée sur les histoires d’utilisateur (user stories), un test d’acceptation est un test qui permet au client (ou au Product Owner) de dire s’il accepte, en fin d’itération, une histoire d’utilisateur développée par l’équipe. Un test est accroché à une story, qui en possède généralement plusieurs.

Chanson agile

Roy Osherove est un gars sérieux, qui a même écrit un livre sur les tests unitaires. C’est aussi un guitariste qui a poussé la chansonnette lors des TechEd à Barcelone, à la fin de sa présentation sur l’intégration continue. Ca s’appelle Every Build You Break et s’est inspiré de Sting et Police, quand même. Pour ceux qui regarderont la vidéo, et en particulier mes étudiants rétifs aux tests unitaires, profitez-en pour lire le premier chapitre de son livre, The basics of unit testing, disponible en téléchargement.

GreenPepper, ça relève les développements

Des spécifications exécutables écrites par le métier ! Hier soir, j’ai fait une web conférence avec François Beauregard, qui m’a présenté GreenPepper. L’idée est assez géniale : permettre aux spécialistes du métier d’écrire les tests associés aux histoires d’utilisateur dans un langage simple et faire en sorte que ces tests soient exécutables. Tout cela dans un environnement collaboratif basé sur un wiki[1] et pouvant être intégré à Jira et Eclipse.

Formaliser les critères d'acceptation

…ou comment rendre inutile la rédaction de spécifications détaillées. Un des gaspillages les plus spectaculaires dans le développement de logiciel est l’écriture de spécifications détaillées suivie de la rédaction d’un cahier de recette, plus ou moins à partir de ces spécifications. Plutôt moins parce qu’en général le cahier de recette est écrit à la fin, à un moment où les specs, écrites au début, ne sont plus à jour depuis longtemps.

Communiquer les tests d'acceptation aux développeurs

Quand et sous quelle forme le directeur de produit fournit les critères de tests d’une histoire d’utilisateur ? Aujourd’hui j’ai défini des tests d’acceptation [1] pour des histoires d’utilisateur[2]. C’est mon boulot de directeur de produit[3] de préciser les critères qui permettront de s’assurer qu’une histoire est complète. C’est un exercice indispensable si on veut automatiser les tests d’acceptation. Si on n’automatise pas cela reste tout de même très important.

Prévisions sur l'Agilité en 2007

Janvier c’est l’époque des voeux et des prévisions. Je viens de lire les prévisions de Fred Cavazza sur le Web2.0 et les anticipations de Louis Naugès sur la bureautique2.0. Et si on faisait l’exercice pour le domaine des méthodes Agiles ? Je n’ai pas la prétention de prédire quoi que ce soit, mais je peux me servir des études que j’ai récoltées en 2006 [1] pour en déduire quelques tendances sur ce que devrait être la diffusion des méthodes Agiles en France en 2007 :

Correction des copies

J’ai posé quelques questions pour les partiels de décembre et maintenant me voilà avec une pile de copies à corriger… Cette année, mes questions étaient ouvertes et la correction n’est pas facile. Il me faut lire entre 5 et 8 pages bien remplies par étudiant. Avec une trentaine d’étudiants, ça doit faire dans les 200 pages. Le plus souvent c’est plein de fautes d’orthographe. Dans la seule copie où je croyais ne pas en trouver, il est écrit à 2 lignes de la fin : “il … est choisit…”.

Savoir finir une histoire

Un principe des méthodes agiles est qu’une “user story” doit être complètement finie en une itération. Pas si facile… Benoît a fait des investigations sur un projet que j’ai initié aux méthodes agiles. Un des constats qu’il fait est que de nombreuses user stories ne sont pas finies en une itération. Quelques unes durent même 5 itérations ! Ce problème est souvent dû à l’accostage développeurs-testeurs. Quand le testeur reçoit le logiciel à tester en toute fin d’itération, au mieux il découvre des erreurs qui ne sont pas corrigées dans l’itération, au pire il diffère ses tests à l’itération suivante.

Test Driven Development

Le TDD est une technique qui est facile à comprendre mais moins facile à mettre en place. Je prépare un cours sur le sujet pour mes étudiants. En attendant, un article de vulgarisation : Test Driven Development, a Portable Methodology

Tests agiles

Dans le numéro de juin de Software Test & Performance : un article (et la couverture) sur l’utilisation de Scrum pour les activités de test et surtout une excellente présentation des différents tests dans un cadre agile par Dean Leffingwell “Take the Agile Path to true Balance”. Il présente bien la problématique des tests dans un développement agile. Il suggère notamment qu’une itération de “durcissement” est bien souvent nécessaire à la fin d’une release, après les itérations “normales”.