Les tests automatiques et l’anneau de pouvoir de l’apprentie développeuse

J’ai beaucoup aimé cet article élaboré à partir du parallèle entre la barre verte du framework de test JUnit et la lumière verte des Green Lanterns. Les Green Lanterns sont des super-héros qui tirent leurs pouvoirs d’un anneau vert.  L’anneau est attribué à des individus capables de combattre la peur. Dans son article, Charles Roth parle de combattre la peur de modifier du code en construisant un filet de sécurité au moyen de tests unitaires.

J’ai la chance de travailler sur un projet ou nous avons écrit depuis le début des tests automatiques à différents niveaux.  Ces test ont jugulé la peur, me permettant d’obtenir un anneau qui confère des super-pouvoirs pour produire en apprenant et apprendre en produisant (#l_oeuf_et_la_poule).  J’ai commencé par développer des tests en même temps que le code fonctionnel, puis les tests en premier et enfin j’ai adopté le TDD [1].  Les pouvoirs de l’anneau se sont accrus au fur et à mesure de cette progression.

Parmi les super pouvoirs conférés par l’anneau aux Greens Lanterns, il y a la capacité de se déplacer à la vitesse de la lumière, celle de matérialiser des objets et une vaste connaissance de l’univers. Voici les super pouvoirs que j’ai tiré de mon anneau :

  • Savoir si ça marche (ou pas) à la vitesse de la lumière : quand je développe, il me faut souvent un certain nombre(ou même un nombre certain) d’essais avant que « ça marche » .  Quelque soit la technique pour vérifier si ça marche, il y a des fortes chances de devoir l’appliquer des nombreuses fois.  Même si c’est aussi simple que lire un log, ça devient vite lourd. Automatiser le test paye rapidement, j’ai pu le constater à mes dépens à chaque fois que j’ai essayé d’en faire l’économie.
  • Savoir ce qui est cassé à la vitesse de la lumière : un truc que j’ai retenu de mon expérience sur les projets de développement est qu’on peut casser des choses auxquels on n’a pas touchées.  Alors n’en parlons même pas de ceux qu’on a touché, surtout quand on est en train d’apprendre. C’est extrêmement pratique de savoir très vite ce qu’on a cassé et pouvoir le réparer discrètement avant de répandre les dégâts sur l’intégration et au delà.
  • La connaissance du code existant : lire les tests pour un bout de code que je connais pas ou que j’ai oublié m’aide grandement à l’appréhender.
  • Matérialiser le focus : Ce pouvoir et les deux suivants sont dus particulièrement au TDD . Quand on crée une fonctionnalité il y a beaucoup de choses à considérer et on peut vite se disperser.  Rester concentrée sur faire marcher le test en cours m’aide à focaliser l’effort.
  • Matérialiser la qualité du code : une fois que le code que j’ai écrit marche, je peux le réécrire, afin de le rendre plus lisible pour ceux qui auront le  bonheur de s’y intéresser plus tard.  Aussi, commencer par me demander comment je vais tester un bout de code, m’amène à une conception plus propre.
  • Matérialiser le fil : Écrire le prochain test à faire passer m’aide à garder le fil entre deux sessions de développement, que ce soit du jour pour le lendemain ou pour quelques jours plus tard (week-end, vacances ou crise de réunionite aiguë).
  • Matérialiser la satisfaction : Quelque chose que j’affectionne dans le métier du développement est d’avoir produit quelque chose de concret  à la fin de la journée.  Les tests passants sont une bonne matérialisation de l’accomplissement  .

Pour toutes ces raisons je me considère test happy autant que test infected. Si  cette heureuse maladie vous tente, voici quelques ressources qui ont aggravé mon cas :

Et vous? Comment est-ce que vous combattez la peur? Avez-vous un anneau de pouvoir?


[1]Le TDD -Test Driven Development ou développement piloté par les tests est une technique de développement qui consiste à appliquer un cycle de 3 étapes : écrire un test qui ne passe pas, écrire le code le plus simple possible qui permet de faire passer le test, améliorer le code en s’assurant que les tests continuent à passer.

Publicités