Un test vert sans avoir été rouge sent mauvais (V2)

Contexte

Dans un contexte Agile, le développement dirigé par les tests (TDD) est incontournable. Ces tests sont le plus souvent unitaires ou d'intégrations car ils aident à construire l'application et couvrent les fonctionnalités existantes en apportant un feedback très rapide. La règle de base du TDD est l'application du cycle RED / GREEN / REFACTOR. Donc on code d'abord le test puis on le fait passer rapidement et enfin on remanie le code si besoin pour éliminer les duplications et améliorer le design.

Un test vert sans avoir été rouge ne sent pas très bon

Un test qui est vert sans passer par l'étape rouge doit interpeller le développeur. En effet, rien ne prouve alors qu'il teste ce qu'il doit tester. Plusieurs scénarios peuvent amener à ce cas :

• Le cas que je m'apprête à coder est déjà couvert donc mon test passe immédiatement
• Je code le test après avoir développé la fonctionnalité; ce n'est plus du TDD et on passe son temps à douter de la pertinence de ses tests.
• Mon test ne teste pas ce qu'il devrait tester

Dans tous les cas, si le test est vert immédiatement, on doit se poser des questions. Au minimum, Il faut faire une contre vérification pour s'assurer de sa pertinence. C'est très simple, il suffit de modifier volontairement le code "under test".

Donc pour qu'un test ait de la valeur il doit nécessairement passer par l'étape rouge.

Et les tests fonctionnels alors?

Les tests fonctionnels servent à tester les "user stories" dans leur globalité en vérifiant que les critères d'acceptance sont bien remplis. Ces tests ou recettes peuvent être exécutés manuellement et l'oeil averti du testeur permet de vérifier que la fonctionnalité est conforme aux attentes du client. Le problème c'est que sur des projets de taille conséquente, cette approche n'est pas viable car le feedback à beaucoup trop long. A mes débuts de développeur, un des projets sur lesquels j'ai travaillé nécessitait 2 jours de tests à plusieurs personnes. Autant dire que lorsque qu'une régression était découverte, le sprint était compromis.

La solution est donc d'automatiser les tests fonctionnels. Oui MAIS! Mais alors attention aux tests qui seront verts sans passer par l'étape rouge! Pour factoriser la vérification de critères, mon équipe avait développé un module spécialisé. Ce module a parfaitement bien fonctionné pendant plusieurs mois. Un jour, ce module a du être modifié pour prendre en compte un changement d'architecture. Puis de nouveaux tests fonctionnels ont été ajoutés à la liste. Ces nouveaux tests ainsi que tous les autres étaient verts pendant plusieurs mois ... mais notre module ne testait plus une bonne partie des critères...

Conclusion

Un test vert sans avoir été rouge ne peut pas apporter la confiance recherchée et doit interpeller le développeur.