Une méthode de travail semble être à la mode dans certains secteurs de nos jours : le développement piloté par les tests. Concrètement, cela consiste à élaborer en premier lieu des tests, munis d’entrées fournies et des sorties attendues, avant de passer à l’implémentation.
Mais même si l’on ne « pilote » pas son développement par les tests, on peut tout à fait en élaborer ; c’est d’ailleurs encouragé.
C’est peut-être une mode, mais il y a des secteurs – comme l’avionique – où les tests font partie du quotidien des développeurs depuis longtemps, très longtemps. Bref !
La question est la suivante : les tests servent-ils à contrôler que l’implémentation est faite sans erreur ?
Il faut bien sûr nuancer, mais en très résumée, mon opinion très personnelle se présente en 2 points.
- on peut tout à fait élaborer des tests après l’implémentation, et c’est très bien ainsi.
- non, les tests ne servent pas vraiment à contrôler que l’implémentation est correcte.
Commençons par ce second point. Quand on parle de tests, entre développeurs, on fait généralement référence à des tests qu’on qualifie dans l’avionique de « tests bas niveau ». Un petit bout de code de test, avec des entrées et des sorties, appelle un petit bout de code de l’application, pour vérifier que les résultats sont corrects.
C’est à différencier des tests dits « de haut niveau », qui consistent plutôt à préparer l’ensemble des entrées, faire tourner l’application, et contrôler l’ensemble des sorties.
Cette nuance est très importante : il y a peu de chances que vous ayez besoin de quelqu’un pour vérifier si vous avez implémenté une petite fonction de la bonne façon. En revanche, il y a très certainement des chercheurs qui sauront vous dire si le programme s’est comporté correctement en ayant subi le scénario de test qu’ils auront préalablement préparé dans un simulateur spécialisé.
D’ailleurs, pour que les tests en général aient un rôle de contrôle de l’implémentation, il faut qu’ils soient élaborés par une personne qui n’est pas celle qui a réalité ladite implémentation. Si l’on écrit dans la même journée les tests et le code, il y a de bonnes chances qu’on reproduise une éventuelle erreur des deux côtés, la faisant passer inaperçue. Il est d’ailleurs très courant que cette méthode de travail soit obligatoire dans l’avionique.
Je considère donc que oui, les tests de haut niveau peuvent servir à contrôler, par l’intermédiaire de personnes hautement qualifiées sur la partie « métier », qu’un programme (ou un pan du programme) est implémenté correctement.
Mais en dehors de cette particularité, les tests, de haut comme de bas niveau, ont surtout un rôle de protection plus que de contrôle : ils nous permettent de détecter les régressions.
Ce qui m’amène donc au premier point. Implémenter un algorithme, tester soi-même le programme, contrôler les entrées et sorties… cela permet souvent de détecter bien des erreurs d’implémentation, sans même passer par des cas de test. Et, quand le sujet est bien frais, qu’on est encore plongé dedans, c’est assez peu coûteux de déboguer et détecter où se situe le problème. Est-ce vraiment strictement nécessaire de commencer par le test ?
En revanche, des semaines, des mois, voire des années plus tard, lorsqu’une autre partie du code sera altérée (probablement par quelqu’un d’autre), il sera beaucoup plus difficile de détecter les éventuels effets de bord de cette modification sur notre algorithme originel. Et il sera bien plus difficile de déboguer à travers l’application pour finalement aboutir au point de rupture.
Les tests, eux, nous permettent de nous prémunir de ce genre de situation. Aussitôt les modifications effectuées, tout effet de bord sera détecté par le biais de l’exécution des tests, ce qui permettra de détecter immédiatement quelles sont les fonctionnalités qui ont régressé.
Un bon test peut tout à fait vérifier, par des cas bien identifiés que l’implémentation est correcte. C’est généralement le but initial.
Mais un bon test va surtout nous assurer qu’elle va le rester durablement.