Le Test Driven Development (ou TDD pour les intimes)
Qu’est que le TDD ? Bonne question ?
Prenons un petit exemple de réalisation d’une méthode en suivant la méthode du TDD (Test Driven Developpement ou en français le développement piloté par les tests).
Nous souhaitons faire une méthode utilitaire qui mette en Majuscule la première lettre d’une String.
Nous commençons donc à écrire le test (avec TestNG)
En faisant le test nous sommes confronté au fait que la classe ainsi que la méthode n’existe pas … il faut donc bouchonner :
Puis on lance le test …
Enfin nous codons la fonctionnalité qui permettra de faire passer les tests:
On regarde la couverture du code (EclEmma) de notre test afin de s’assurer que l’intégralité de la classe est testé :
A noter ici que la classe est considérée comme non couverte par le test, et c’est normal car le constructeur de la classe n’a pas été appelé étant donnée que nous testons une méthode statique.
C’était juste un petit exemple pour montrer l’utilisation de TestNG et EclEmma en suivant la méthode du TDD. Nous avons commencé par codé le test, puis nous avons codé la fonctionnalité afin que le test passe. Le plugin de couverture de code, nous a permis de vérifier que l’intégralité de notre code à bien été couvert par le test.
En espérant que cette petite introduction au Test Driven Developpement vous donne envie de mieux couvrir vos développement avec des tests unitaires, l’expérience montre que le temps passé à écrire des tests est bien moindre que le temps passé à faire évoluer un code non couvert.
Comme tu écris une méthode pour affecter le premier caractère, il serait sage d’inclure les chaines de taille 1 dans les cas limite testés.
Assert.assertEquals( »T », StringHelper.capitalize( »t »));
Sur le coup j’ai cru que l’outil de couverture buggait : la contre-partie && > 1 pour moi n’avait pas été couverte, mais si en fait, avec le test « ».
Ainsi que tester les caractères qui n’ont pas de majuscule.
Assert.assertEquals( »1test », StringHelper.capitalize( »1test »));
Ce qu’il y a d’extraordinaire avec les outils de couverture de test, c’est qu’ils disent ce qu’on n’a pas testé. Je suis passé sur des projets où il fallait absolument avoir 100% de couverture (super, faut que je teste tous mes getters !), et alors on considérait le test était parfait. heu… comment dire…
Et une dernière petite remarque, pas très importante puisque c’est pas le focus du sujet du post : en général, pour une classe utilitaire, on la met final, et avec un constructeur explicite private.
public final class StringHelper {
private StringHelper() {
// prevent instantiation
}
}
Et ya un souci avec ta deuxieme image.
grrr. le html, n’est pas « escapé » dans les commentaire.
Et ya un souci avec ta deuxieme image (elle apparait comme un lien a href, et non comme un img).
@Cyril
Merci pour ces commentaires.
J’ai corrigé l’image. (et tes caractères html non « escapé » !)
Concernant une couverture à 100% ça ne m’est encore jamais arrivé ! On attend ton retour d’expérience sur ce sujet !