Dans un post précédent, nous proposions d’adapter la recommandation de Robert C. Martin suivante :

Nous honorerons notre équipe en testant tout ce qui peut être testé

en

Nous honorerons notre équipe en testant tout ce qui doit être testé

Mais que voulais dire Robert C. Martin en disant « tout ce qui peut être testé » ?

Dans le livre Clean Code, il écrit :

Disposer d’une suite de tests automatisés qui couvrent l’ensemble du code de production est indispensable pour conserver une conception et une architecture aussi propres que possible.

Il s’agit donc de créer suffisamment de tests pour passer dans tous les embranchements du code. Le moindre « if » ou « else » doit faire l’objet d’un cas de test. Ni plus ni moins :

Vous devez uniquement écrire le test unitaire suffisant pour échouer

Vous devez uniquement écrire le code de production suffisant pour réussir

Ces 2 propositions semblent être le Yin et au Yang du code parfait. Juste ce qu’il faut pour fonctionner comme il faut. Un parfait équilibre très séduisant… tellement qu’en le lisant, nous sommes presque incités à abandonner tout ce que nous faisons pour aller reprendre notre dernier projet et le remettre au carré !

Pourtant nous codons souvent sans faire de tests. La réalité est que nous n’avons pas le temps. Très souvent, nous codons un truc, nous testons manuellement que tout va bien et nous passons à autre chose. Si un bug se présente un jour, on reprend le projet et on corrige ce qui ne va pas. Et l’on peut admettre que cela se passe souvent bien. A la fin de l’année, sur l’ensemble de nos projets, nous pouvons dire que nous avons passé moins de temps à corriger les problèmes que celui que nous aurions pris à créer des tests unitaires systématiquement.

Il y a pourtant au moins 4 cas où nous devons absolument tester notre code :

• Les processus critiques : quand nous travaillons sur un traitement qui a des conséquence irréversibles. Par exemple une expédition de commande, un remboursement, etc.
• Le code obscur : il s’agit de traitements dont les implications ou les effets de bord ne sont pas visibles immédiatement. Il est important de prévoir tous les tests nécessaires pour que les personnes qui feront évoluer le projet dans le futur ne commettent pas de régressions parce qu’ils n’ont pas compris toute la portée du traitement ou ses effets indirects.
• Les algorithmes complexes : dès que l’on commence à devoir réfléchir pour déterminer la sortie d’un algorithme en fonction de son entrée.
• Les applications utilisateurs : quand une fonctionnalité, une page web, ou une application est prévue pour être utilisée par nos clients. Il est inenvisageable que nos clients soient bloqués par un problème informatique car un bug peut potentiellement tous les bloquer. Une des difficultés est que les utilisateurs se comportent tous différemment, avec des appareils et des contextes variés.

Ces 4 situations mal testées sont la source de problèmes différents :

• Les processus critiques : Une erreur peut coûter très cher à l’entreprise
• Le code obscur : Une erreur peut rester invisible très longtemps
• Les algorithmes complexes : Une erreur peut être très longue à corriger
• Les applications utilisateurs : Une erreur peut créer un manque à gagner

Finalement, tout pouvant être réduit à une question d’argent, nous pouvons observer que le prix à payer pour ces erreurs peut être bien plus élevé que celui lié à la création des tests unitaires. À moins de s’engager dans des paris risqués, il nous est impossible de prévoir quand les erreurs se produiront. Si nous cherchons à faire notre travail correctement, nous ne pouvons pas nous en remettre au hasard. Ce sont des situations où des tests unitaires doivent être faits. Il est important que nous identifions ces situations et que nous réalisions les tests nécessaires de manière approfondie.