Post IT
Développement piloté par les tests (Test Driven Development)
Arnaud BUCHOUX - lundi 28 septembre 2009 à 11:11Les tests sont souvent considérés comme une véritable plaie par les développeurs. Bon nombre d’entre eux délaissent systématiquement cette étape dans un projet. Et quand ils s’y attellent, ils la perçoivent comme une contrainte. La raison évoquée est simple : passer du temps à écrire des tests, c’est passer moins de temps à développer. En fin de projet le temps devient précieux et les tests passent en second plan par rapport à la fin des développements.
L’idée du développement piloté par les tests est de voir les tests non plus comme l’étape finale de vérification du fonctionnement d’un projet mais plutôt comme la base de la réflexion des développements qui guidera le développeur tout au long du projet.
Pourquoi faire des tests ?
Ou plutôt, que se passe-t-il lorsqu’un projet n’est pas testé ? La première réponse, nous la connaissons tous. Un projet peu ou pas testé se traduit par un nombre important de bugs. Mais cela va plus loin, c’est la maintenabilité du projet qui est en jeu. Sans véritable procédure de test, l’introduction d’un nouveau composant dans un applicatif est susceptible d’apporter une nouvelle anomalie ou pire, une régression.
Le temps est également une information à prendre en compte. Le développement d’une application mal testée prend beaucoup plus de temps. Les vérifications manuelles de non régression entraînent de coûteux allers et retours entre l’interface et le code. Bref, en voulant économiser le temps attribué aux tests, nous perdons pied à tenter d’inclure des fonctionnalités instables et difficilement maintenables.
Principe du développement piloté par les tests
Le principe du développement piloté par les tests est de faire intervenir les tests dès le début du projet. Voici comment se déroule une phase de développement.
Dans un premier temps, pour répondre à un besoin bien précis, un test unitaire est écrit. Ce premier test unitaire se veut précis. Il a pour but de tester une fonctionnalité et une seule. Le but est de définir un grossier algorithme qui pourra faire appel à des méthodes qui n’ont d’ailleurs pas encore été implémentées. A l’exécution, le test va échouer, et c’est ce que nous voulons : réfléchir à un algorithme mais pas à son implémentation.
Ensuite, nous allons nous atteler à l’implémentation elle-même. Et celle-ci va se contenter du minimum tout d’abord. Elle devra passer le test avec succès en un minimum de code.
L’ultime étape est dédiée à l’amélioration et à la factorisation du code. La procédure de test sera une fois de plus lancée après cela pour s’assurer du bon déroulement.
Et ainsi de suite pour chaque développement...
Bénéfices
Les bénéfices de l’écriture des tests en amont sont multiples. Ecrire les tests en premier lieu force le développeur à réfléchir à l’algorithme et à envisager les différents cas de figure possibles. Vérifier la validité des paramètres d’une fonction, vérifier les cas limites ou bien encore gérer des exceptions sont autant d’éléments que le développeur oublie d’implémenter car il pense toujours au cas d’utilisation le plus classique.
Il va pouvoir détecter rapidement les anomalies dans son code. Et si il en redécouvre une qui n’est pas déjà couverte par ses tests unitaires, il en profitera pour en écrire un nouveau qui vérifiera ce cas particulier.
Les tests documentent le code. A eux seuls, ils nous renseignent sur la façon d’utiliser une méthode et en ce sens font foi quant à la façon d’utiliser une fonctionnalité. Ils ne se substituent pas à une documentation classique mais en sont complémentaires.
Aucun commentaire pour cet article