Après une session sur la notion de « Done » sympathique, je suis allé écouter une discussion sur la mise en place d’un Pipeline d’intégration continue. Finalement la discussion s’est transformée en présentation du logiciel « Cruise » par ThoughWorks. Et comme je n’ai pas de temps à perdre à regarder une présentation commerciale, je suis allé rejoindre un débat sur les mocks dans une salle voisine. Sur scène, David Gageot de Tech4Quant et Steve Freeman. David est bien connu de la communauté Java sur Paris, et c’est une étincelle qui a le mérite de faire avancer nos habitudes. Steve Freeman est anglais, c’est l’un des auteurs du livre « Mock Objects and Test Driven Development« . C’est aussi un speaker reconnu qui a présenté 2 sujets à Agile 2009. Son expérience dans notre industrie est intéressante. Il explique ainsi que l’excitation récente sur TDD est paradoxale alors qu’en fait cette pratique existe depuis longtemps dans notre industrie… On en parle plus mais il faut bien comprendre que dans certaines industries comme l’électronique par exemple, la conception pilotée par les tests est le seul moyen de fonctionner.
Je n’ai pas noté tout ce qui s’est dit pendant cette séance, mais il était intéressant de voir Steve plus ou moins découvrir le code de David, et l’utilisation de Mockito. Avant que je n’aille plus loin : Mockito rocks ! Prenez easyMock et Mockito, le premier donne mal au ventre, vous fait perdre vos cheveux. Le deuxième est plus digeste, simple et diablement plus intelligent que son copain.
Sur le code présenté, nous essayons d’identifier des bonnes pratiques des Mocks. David recommande de ne pas utiliser de méthodes private dans des tests unitaires. Cela n’améliore pas la lisibilité. D’ailleurs si vous n’arrivez pas à lire ce que fait un test, c’est que la méthode testée est trop compliquée.
David j’ai une idée : pourquoi ne pas développer un petit plugin pour Eclipse/IDEA IntelliJ qui afficherait la complexité cyclomatique dans la classe de test unitaire, au niveau de la méthode du test unitaire ? Cela donnerait un indicateur de ce que l’on est entrain de tester, et donc une idée de l’effort à fournir…
Steve appuie aussi l’importance du nom de votre méthode de test. Même si l’anglais n’est pas votre langue native, il est important de trouver un certain phrasé sur les noms des méthodes des tests unitaires.
Nous avons une discussion sur les pratiques à mettre en place pour mocker les DAO. Gojko Adzic rappelle qu’un pattern comme Repository présenté par Martin Fowler, permet de mettre une abstraction entre le moyen de stockage et les données. Ecrire un Repository c’est très simple. Prenez cet article en C# qui est assez complet, et vous aurez compris le principe.
Voir aussi cet article inspiré par Eric Evans, le père du Domain Driven Design, qui est passé au Paris JUG l’été dernier, et cet article de Christian Bauer qui critique le pattern Repository si vous voulez avoir un autre son de cloche.
Après pas mal de discussions animées, que je n’ai pas noté (pour une fois) nous avons fait une pause déjeuner.
Je vous laisse regarder les articles, je me prépare pour l’article suivant sur les tests d’acceptance.
Je reviens dans 5 minutes…
0 no like
