La conception d'un logiciel, site internet, web service, API… comporte différentes étapes : • analyse ; • spécifications techniques et fonctionnelles ; • développement ; • tests (unitaires, intégrations, validations) ; • recettes ; • maintenance. Cette liste n'est pas exhaustive, elle peut varier, être réduite ou complétée selon le contexte technique, client, budgétaire… La conception d'un logiciel et ses étapes s'orientent autour du cycle de développement, il en existe plusieurs : • modèle en cascade ; • cycle en V ; • cycle en spirale ; • cycle semi-itératif ; • cycle itératif. Chaque cycle possède ses avantages et ses inconvénients, ainsi que des défenseurs et des détracteurs. Ils ont tous un point commun, placer en premier l'écriture du code avant la phase de tests dans le cycle de développement. Cet ordre chronologique paraît logique, on teste ce que l'on vient de produire, pourtant une autre technique préconise l'écriture des tests avant l'écriture de l'application.
I - Le développement par les tests
Commençons cet article par la définition du TDD (source Wikipédia) : Le Test Driven Development (TDD) ou en français le développement piloté par les tests est une technique de développement de logiciel qui préconise d'écrire les tests unitaires avant d'écrire le code source d'un logiciel. Contrairement à d'autres cycles de développement logiciel (modèle en cascade, cycle itératif) plaçant les tests en fin de cycle, le TDD place les tests en première place dans le cycle de développement. C'est une méthode dans laquelle l'écriture des tests automatisés dirige l'écriture du code source.
La mise en place de la méthode TDD offre de nombreux avantages au sein du développement d'un logiciel. Voici les avantages apportés par l'emploi de cette méthode.
Les tests unitaires sont réellement écrits
Comme évoqué dans les autres cycles de développement, les tests sont effectués à la fin d'un projet. D'après plusieurs enquêtes, 70 % des projets informatiques se terminent en retard, pour diminuer ce retard la phase de test est souvent réduite au strict minimum. Le fait de commencer par rédiger les tests permet de s'assurer que les tests seront écrits.
Fiabilité du code
En suivant la méthode traditionnelle, le développeur écrit une fonctionnalité et va ensuite procéder aux tests afin de s'assurer que ce qu'il a codé est valide. Mais inconsciemment le développeur teste son code comme il l'a conçu, le nombre de bogues trouvés est peu important et le risque de passer à côté de bogues est élevé.
Analyse détaillée et plus précise
En effet, lorsque le développeur écrit du code de test pour tester une implémentation qui n'existe pas encore, il va devoir penser aux détails de la méthode dont il a besoin pour écrire la spécification. Aussi, il va alors s'interroger sur le nom de la méthode, sa valeur de retour, ses paramètres, son comportement…, cela permet de clarifier la conception et d'écrire seulement du code utile.
Vérification démontrable,
répétable et automatisée Le fait de disposer d'un grand nombre de tests permet de s'assurer de la solidité et garantie du code.
Absence de régression
Lorsqu'un développeur modifie une méthode existante lors d'une phase de factorisation, il peut relancer les tests unitaires afin de s'assurer que sa modification n'a pas impacté l'existant et bénéficie d'un retour immédiat.
Couplage plus faible et conception simplifiée
Le TDD impose d'écrire le code des tests en peu de temps ce qui amène le développeur à concevoir du code avec un faible couplage et avec un niveau relativement simple. Malgré les avantages listés ci-dessus, il faut bien comprendre que le TDD n'est pas une réponse miracle aux problèmes de développements dans les équipes, il n'empêche pas les bogues et les erreurs d'analyse, de conception… Quand on évoque le TDD, un inconvénient revient souvent :
Plus de travail
Depuis longtemps le développeur n'aime pas effectuer les tests, il trouve cette partie du travail fastidieuse, non valorisante et limite hors cadre de sa fonction. En écrivant des tests unitaires, le développeur a plus de travail.
