Développement Dirigé par les Tests
Fabian Piau | lundi 3 août 2009 - 13:06Je profite de mon dernier article sur l’Intégration Continue pour vous présenter une nouvelle bonne pratique de l’eXtreme Programming (XP): Test-driven Development (TDD) ou Développement Dirigé par les Tests. En fait, l’Intégration Continue est fortement liée à ce concept. Pour en savoir plus sur les bonnes pratiques de l’XP, vous pouvez cliquer sur le logo juste ci-dessous.
Les tests représentent une partie critique dans le développement de logiciels. TDD est une technique, où les tests sont écrits progressivement, dès le début du projet, et surtout avant l’implémentation du code. Pour aider le développeur dans cette tâche, des outils d’automatisation de tests existent. Par exemple, la série XUnit est une des plus populaires.
TDD en quelques mots
D’abord, le développeur imagine et écrit un test (un test qui va échouer car le code qu’il teste n’a pas encore été écrit). Ensuite, il écrit le code dans le but de passer (réussir) le test (juste le code qu’il faut, pas plus!). Finalement, le développeur ré-arrange son code (cette étape s’appelle le « refactoring »), et il s’assure que le test passe toujours. Refactoriser le code est une étape importante de TDD, elle vise à améliorer le code qu’on a écrit tout en gardant les mêmes fonctionnalités. Par exemple, cela peut être une suppression de variable inutilisée, une diminution de la duplication du code, un ajout de commentaire, une amélioration de sa lisibilité, etc.
Ce cycle est répété plusieurs fois par heure, chaque cycle concernant une fonctionnalité très précise du logiciel.
Généralement, les développeurs modélisent, codent, et à la fin seulement, ils testent. L’inversion entre la première et la dernière étape est très déconcertante, mais cela ne veut pas dire pour autant que c’est une mauvaise chose…
Bien au contraire, les avantages sont multiples. Pour ne citer que les plus évidents, le taux de couverture du code par les tests se rapproche du 100%, la qualité du code s’en trouve améliorée, la découverte des bogues est faite en amont, les développeurs ont une meilleure confiance dans leur application (ils sont certains que ce qu’ils ont codé est fonctionnel et a été pleinement testé). Rappelons, encore une fois, que plus un bogue est découvert tôt dans le projet, moins il coûtera cher.
S’agissant que d’une introduction, mon article s’arrête ici. Mais, je vous invite à vous renseigner davantage sur la toile si le concept vous intéresse ou vous intrigue.
RSS - Articles
Commentaires récents