Juniors ! Plus d’excuses pour ne pas écrire des tests.

J’ai beaucoup lu sur les avantages des tests automatiques, j’ai même écrit quelques tests unitaires pendant mon « spare-time », afin de voir de quoi il s’agit. Mais, ils n’étaient pas suffisants pour répondre à cette question — que fort probablement vous vous êtes posés — : pourquoi devrais-je perdre du temps à écrire des tests et retaper certaines logiques ?!

Personnellement, « I saw the light » et j’ai trouvé ma réponse après avoir écrit des tests unitaires dans le cadre d’un projet concret.

Dans la suite de ce billet, j’essayerai de mettre en place une enum, non exhaustive, des différents avantages que j’ai pu étayer d’exemples concrets.

Mais laissez-moi commencer par un aperçu sur le contexte de mon intervention.

Je développais un module faisant appel à des briques développées par d’autres gentils développeurs.  Mon module serait utilisé par d’autres composants, dont je n’étais pas l’auteur. Tous ces modules étaient en cours d’élaboration ainsi que les « APIs » qu’ils exposaient.

  • Le testing m’a permis d’être plus productif. En fait, j’ai pu travailler en isolation, indépendamment de l’avancement des autres modules. Écrire des tests unitaires m’a permis de fournir et soumettre du code testé, donc vérifié ; ce qui lui confère une qualité proportionnelle au nombre d’aspects couverts par les tests. Ceci était possible grâce à quelques outils et techniques.

Avec l’IoC de Spring et le TestContext Framework, j’ai pu créer des stubs qui se substituent aux  beans qui me seraient fournis par d’autres modules. Avec Mockito, un framework de mocking, j’ai pu tester en isolation le comportement d’une de mes méthodes malgré qu’elle fasse appel aux services d’autres objets dont je ne suis pas l’auteur. Ceci était possible en « mockant » ces objets.

  • Un deuxième avantage : au fur et à mesure de l’écriture des tests, je me suis retrouvé constamment à remanier mon code afin de le rendre testable en unité et fournir une meilleure implémentation. Résultat, mes méthodes étaient plus concises, plus courtes, « plus réutilisables », plus faciles à lire et à comprendre et IoC était une monnaie courante. Pour vous donner un exemple, une fois j’étais amené à traiter un nouveau cas en utilisant une logique que j’ai déjà implémentée, mais qui était un peu complexe et un peu longue. Après remaniement et grâce à une amélioration continue de la qualité du code, j’ai pu traiter ce nouveau cas en quelques lignes et d’une façon quasi intuitive.

 

  • Les tests sont votre filet de sécurité pour détecter les régressions. Ce troisième avantage est une assurance gratuite qui accompagne le remaniement. Combien de fois avez-vous perdu un temps précieux à déboguer après avoir remanié un bout du code en essayant d’améliorer l’implémentation ou juste après un petit changement du nom d’un attribut ou d’une méthode. Concrètement, je vous ai raconté comment l’API de certains modules que j’utilisais n’était pas définitive ; et on a fini par la modifier. S’aligner sur ces modifications, m’a demandé de ré implémenter autrement certaines logiques, qui n’étaient pas triviales. Afin de vérifier ma nouvelle ré-implémentation, je n’ai lancé que les cas de test que j’ai jugés utiles et pertinents. Ils ne passent pas. J’ai passé un bout de temps à essayer de débusquer le bug, mais sans succès. Lorsque j’ai lancé tous les tests, ça ne m’a pas pris plus de quelques minutes pour trouver et corriger le bug.

 

  • Enfin, les tests sont une excellente documentation pour les développeurs. Une fois, j’ai dû utiliser une certaine méthode qui était hors ma juridiction. Son utilisation devrait être précédée par un setup bien particulier. Pas de problème ! Le cas de test écrit pour cette méthode était plus que suffisant pour tout savoir sur son utilisation. Pour faire « court » : l’intérêt de l’exemple est bien connu ; et les tests unitaires sont des exemples qui montrent comment utiliser l’API.

 

Pour conclure, j’ai écrit ce billet en me basant sur mon vécu en tant que développeur junior qui vient de faire ses premiers pas dans le monde professionnel. J’ai essayé d’illustrer à travers des exemples concrets quatre avantages que confère la pratique du testing à savoir : être plus productif, améliorer l’implémentation, détecter plus rapidement les régressions, et jouir d’une documentation, étayée par des exemples, de l’utilisation de l’API.

J’ai pu tirer profit de tous ces avantages alors que j’écrivais les tests au fur et à mesure de mon avancement dans le code et parfois un peu plus tard. Et J’ai hâte de découvrir le résultat en poussant cette pratique à son extrême en commençant par les tests comme le préconiser le Test-driven development (TDD).

Un dernier point : une des motivations derrière ce billet était ma volonté d’être actif et adhérer concrètement à l’esprit ouvert de l’écosystème Java, que je vois comme une source de richesse inouïe conduisant à des synergies et des collaborations qui profitent à tout le monde.

Enfin, je remercie Matthias ANGLADE, Jean-Max MARIE SAINTE et Eric SIBER pour leurs encouragements et leurs conseils.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *