Imaginez ceci : vous venez d’écrire du code pour une nouvelle fonctionnalité. Vous êtes en train d’écrire des tests unitaires. Pendant que vous écrivez vos tests, vous commencez à avoir une crise existentielle. « Pourquoi est-ce que j’écris ces tests ? » vous vous demandez. « J’ai déjà vérifié manuellement que mon code fonctionne, et j’ai même demandé à un autre développeur de le tester lui-même. À quoi ça sert? »
La réponse réside dans une réalisation cruciale : Vos tests sont pour l’avenir.
Bien sûr, ils sont également disponibles pour le moment et peuvent vous aider à détecter certains cas extrêmes que vous avez peut-être oubliés lors du développement de votre nouvelle fonctionnalité. Mais les tests sont principalement destinés à ceux qui travailleront sur votre code dans les mois et années à venir.
Explorons comment c’est vrai.
Documentation
Les tests servent de documentation sur la façon dont une certaine fonctionnalité doit se comporter.
Les tests sont essentiellement des exigences de produit écrites sous forme de code. Les développeurs qui travailleront plus tard avec cette fonctionnalité peuvent avoir des questions sur l’intention du code ou sur la manière dont certains scénarios doivent être traités.
Plutôt que de creuser dans d’anciens tickets JIRA ou une documentation potentiellement obsolète hébergée ailleurs, les développeurs peuvent passer à la suite de tests directement dans leur IDE. En examinant les cas de test, ils peuvent avoir une assez bonne idée du fonctionnement de la fonctionnalité.
Éviter les régressions
Les tests vous aident à éviter les régressions dans votre base de code lorsque vous développez de nouvelles fonctionnalités.
Bien que ces nouvelles fonctionnalités puissent sembler sans rapport avec un morceau de code existant, il est toujours possible que les deux soient connectés d’une manière que vous avez manquée. Une suite de tests solide détectera les zones où vous avez par inadvertance affecté le code existant de manière négative.
Sans tests en place, vous ne pouvez jamais être tout à fait certain que le nouveau code que vous écrivez fonctionne bien avec l’ancien code sans effectuer des tests manuels approfondis (et fastidieux).
Refactorisation
La raison la plus impérieuse d’écrire des tests et pourquoi ils sont pour l’avenir est qu’ils vous permettent de remanier en toute confiance.
Je suis sûr que vous avez travaillé quelque part qui a une grande application héritée que l’équipe prend en charge. Il y a quelque chose d’absolument crucial enfoui dans cette application héritée. C’est peut-être votre logique commerciale de traitement des paiements. C’est peut-être votre code d’authentification.
Quoi qu’il en soit, il est essentiel à la fonctionnalité de base de votre application, et tout le monde a peur d’y toucher. Il est vieux et semble fonctionner correctement, mais il s’est transformé en un énorme désordre de code spaghetti que plus personne ne comprend vraiment.
Et pourquoi tout le monde a-t-il peur de travailler dessus ? Parce qu’il n’a pas de tests ! Et cela signifie que toute ligne de code que vous modifiez ouvre la possibilité de casser quelque chose à votre insu. Cela signifie que chaque petite modification que vous apportez à cette fonctionnalité doit être fortement testée manuellement. Cela signifie que vous devenez extrêmement nerveux et croisez les doigts lorsque vous cliquez sur le bouton « Envoyer » pour fusionner votre code.
Maintenant, dans une réalité alternative, imaginez ce même élément de fonctionnalité de base, mais avec une belle suite de tests qui couvre correctement le code. Lorsque vient le temps de refactoriser le code, vous pouvez le faire en toute confiance. Pourquoi? Parce que vous saurez si vous avez cassé quelque chose. Si les tests réussissent tous maintenant, que vous apportez des modifications et que vous avez maintenant quelques échecs, il est clair que quelque chose ne va pas encore.
Mais ce n’est pas troublant car vous avez détecté les erreurs avant de publier ces nouvelles modifications en production et vous êtes en mesure de trouver la cause première et de vous assurer que votre refactor fonctionne correctement cette fois.
Conclusion
Les tests sont pour l’avenir. Ils fournissent de la documentation, vous aident à éviter les régressions et vous permettent de refactoriser en toute confiance.