English version available

Je 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.

 English version available

Imaginez un projet Java avec une équipe de 60 développeurs. Après 6 mois de développement sur le projet, l’équipe décide de créer une release (= une version finale de test avant sa livraison au client) pour pouvoir tester l’application. Mieux vaut tard que jamais comme dit le proverbe, sauf que…

Après 3 tentatives pour faire la release se soldant par des échecs, il est décidé de constituer une équipe de 6 personnes pour effectuer cette tâche. Et voici le résultat: 2 ans de retard !

La solution à ce type de problème est la mise en place de l’Intégration Continue (« IC », « Continuous Integration » ou « CI » en anglais).

Comme j’ai trouvé qu’il n’y avait vraiment pas beaucoup de documentation en français sur le sujet, je me suis lancé dans la rédaction d’un dossier complet.

Voici un extrait de la préface pour vous donner une idée de ce que vous y trouverez.

Ce dossier présente l’intégration continue (IC), l’une des pratiques agiles les plus populaires. Il est à la fois une synthèse et un recueil des bonnes pratiques sur l’IC. Ce document répondra également aux questions qui peuvent être soulevées par une telle pratique. La partie concernant le retour d’expérience sera amenée à évoluer, l’intégration continue est un processus long. Pour l’instant, l’objectif principal de ce document est de vous présenter le concept. Ainsi, vous trouverez une description de cette méthode, les avantages qui en découlent, mais aussi les difficultés qui peuvent survenir et comment les surmonter. Vous y trouverez un exemple parlant sous la forme d’un scénario réaliste, nous parlerons aussi des évolutions possibles de l’intégration continue. Autrement dit, ce dossier contient tout ce qu’il faut savoir avant de se lancer dans la mise en place de l’IC au sein de son entreprise.

Voici un schéma qui explique brièvement le fonctionnement de l’IC, étape après étape.

Schéma IC (cliquez pour voir en plein écran)

Et voici le lien pour lire le dossier (50 pages environ):