Avantages
Si l'on s'assure en outre que le test provient d'une décomposition d'un besoin client, ces étapes assurent que :
- le code obtenu ne cherche pas à implémenter des services non nécessaires (principe de YAGNI - You Ain't Gonna Need It) ;
- la couverture des tests est optimale ;
- les modifications futures sont possibles et sans risques ;
- les fonctionnalités offertes par le code sont claires car documentées par le test-même.
Les tests obtenus sont typiquement bien plus nombreux que dans un projet classique. Il n'est pas rare que, parmi les lignes de code obtenues, plus de la moitié correspondent aux tests écrits.
Le temps passé à écrire ces tests peut sembler excessif à une personne extérieure. Cela n'est vrai qu'aux débuts des développements. Après quelques semaines, le retour sur investissement est réel. Il est encore plus frappant vers la fin des développements, où les corrections de dernière minute pourront se faire sans danger. C'est le meilleur moyen d'éviter les compromis classiques "nous n'écrirons pas de tests car nous n'avons plus le temps" !
TDD chez Valtech
Nos consultants connaissent et pratiquent TDD chez nos clients. L'outillage classique (xUnit) est associé à des moyens avancés comme les "mock objets" avec EasyMock ou JMock, Spring qui aide au découplage des couches créées, dbUnit pour simplifier la manipulation d'une base de données, HSQL pour créer une base embarquée dédiée au test.
Enfin, nous recommandons l'utilisation de Maven et CruiseControl pour automatiser le lancement des tests réalisés.
1. Ajouter un test simple.
2. Lancer tous les tests.
3. Modifier le code de l'application.
4. Lancer les tests pour vérifier la correction.
5. Ré-usiner pour supprimer la duplication de code.