Devons-nous écrire nos tests avant notre code ? Il y a quelques temps, nous nous disions qu’à l’heure actuelle, dans notre équipe, il nous semblait plus réaliste de se fixer pour objectif de les faire le même jour.

Ce qui est sûr c’est que si nous attendons pour écrire nos tests, nous ne les écrirons jamais. D’une part nous n’aurons plus la tête à le faire ou nous aurons oublié certains détails. D’autre part si nous attendons trop, le code aura probablement déjà été utilisé en production ou en condition réelle. Si nous n’avons pas détecté d’anomalies, nous considérerons que les cas d’utilisation standard auront alors été validés.

Il n’y aura plus d’intérêt à prioriser l’écriture de tests plutôt que de travailler sur quelque chose qui aura plus de valeur pour l’entreprise. Le danger réside alors dans les cas d’utilisation non standards ou moins fréquents que nous n’aurons pas testé.

Dans le paradigme du TDD (Test Driven Development), l’écriture des tests doit se faire avant le code. Les raisons sont très valables :

• S’assurer que le test peut échouer: Si le test est écrit après le code, il est possible que le test soit incorrectement écrit de manière à passer toujours, même si le code a des défauts. Écrire le test avant le code permet de voir le test échouer d’abord, ce qui assure que le test est valide et capable de détecter des erreurs.
• Éviter le surcodage: L’écriture des tests en premier aide à éviter de coder des fonctionnalités inutiles. On n’écrit que le code nécessaire pour passer les tests, ce qui permet de rester concentré sur la réalisation des objectifs de développement.
• Réduction du temps de débogage: Les erreurs sont trouvées plus tôt dans le cycle de développement, ce qui peut réduire le temps passé à déboguer plus tard.

Il y a pourtant certains inconvénients :

• Difficulté à prévoir les besoins: Il peut être difficile d’écrire des tests pour un code qui n’a pas encore été écrit, surtout si le périmètre du projet n’est pas complétement défini au départ. C’est souvent le cas lorsque nous découvrons une API ou que nous sommes dans une phase exploratoire et que nous utilisons une nouvelle librairie par exemple. Au fur et à mesure de l’avancement, les tests écrits précédemment peuvent devenir obsolètes. Cela peut entraîner une perte de temps à réécrire les tests.
• Échec prévisible du test: Dans le TDD, un test est d’abord écrit pour échouer, puis le code est écrit pour faire passer le test. Cela peut sembler contre-intuitif ou décourageant pour certains développeurs.
• Augmentation du temps de développement initial: L’écriture des tests avant le code peut augmenter le temps de développement initial. Il faut du temps pour écrire des tests, et ce temps est pris avant même de commencer à écrire le code fonctionnel. Cela n’est parfois pas rentable pour de petits projets.

Un point qu’il faut prendre en compte également est que l’écriture de tests efficaces nécessite une certaine compétence. Apprendre à écrire de bons tests unitaires peut prendre du temps. Il faut maitriser les principes de la conception de logiciels pour créer un code modulaire et testable. En TDD, nous devons même apprendre à écrire notre code différemment. Pour qu’il soit testable il est parfois nécessaire d’augmenter son niveau d’abstraction et par exemple d’utiliser l’injection de dépendance pour rendre le code indépendant de l’OS, des bases de données ou d’APIs externes. Cela complexifie alors l’architecture du code et rallonge le temps de développement.

Notre équipe est jeune et nous explorons chaque semaine de nouvelles librairies ou APIs. Dans notre situation, nous pouvons nous fixer 3 règles raisonnables :

• écrire nos tests unitaires avant le code dès que nous le pouvons
• sinon, écrire nos tests dans la journée
• ne jamais attendre le lendemain