La maturité face aux tests

En tant que discipline assez récente, le développement logiciel est un domaine qui se cherche encore en termes de technologies et de processus. Malgré tout, il y a un certain nombre de pratiques qui commencent à avoir fait leurs preuves et faire de plus en plus l’unanimité.

Pour ce qui concerne la maîtrise de la qualité des logiciels, il existe différentes techniques. La revue de code en fait partie, mais l’écriture de tests automatiques reste aujourd’hui la solution qui semble être la plus efficace et adaptée dans le cas général.

Pourtant, à mon goût, il y a bien trop peu de développeurs aujourd’hui qui écrivent des tests. J’ai essayé de classer les développeurs en quatre niveaux qui représentent leur maturité face aux tests. Comme toute analyse qui consiste à classer des individus dans des catégories, cette approche est forcément caricaturale.

Je n’ai pas besoin de tester

Il y a des développeurs sûrs de ce qu’ils font, ils ont entièrement confiance en eux et « ne voient pas pourquoi ça ne fonctionnerait pas ». C’est souvent le cas des débutants qui, après quelques années, finissent par se rendre compte qu’ils peuvent se tromper et qu’écrire des tests a une réelle valeur. Malheureusement (à mon sens en tout cas), il y a trop de développeurs qui restent coincés à ce stade et qui n’arrivent pas à se remettre suffisamment en question, et ce malgré les années qui passent.

L’article tester c’est douter que j’avais écrit à l’occasion du premier avril est en fait une caricature de ces gens-là. Quitte à être un peu rabat-joie, je me permets de rappeler que l’Homme n’est pas infaillible. Personne à ma connaissance n’est capable de jamais se tromper, surtout dans notre domaine où les sources de potentiels problèmes sont incroyablement variées. Pour autant, l’Homme est capable de faire des choses extraordinaires, pour peu qu’il soit un peu vigilant.

Malheureusement, le monde du développement actuel ne nous pousse guère à passer ce stade. Les tests ont l’image de tâches ingrates et pas intéressantes. Écrire des tests, c’est souvent vu comme une punition. Et les managers et autres chefs de projet n’aident pas, puisque bien souvent ils considèrent les tests comme une activité secondaire dans un projet qu’on fera un jour, quand on aura le temps…

Un certain nombre de développeurs sont absolument insensibles à ces questions-là. Pourtant, il ne s’agit simplement que d’avoir un simple déclic. Essayer de pousser des gens à passer au stade suivant peut parfois être vraiment désespérant. J’aurais tendance à dire qu’un des moyens d’y parvenir est de les responsabiliser davantage, en arrêtant de considérer que la présence répétée de bugs est une simple normalité. Malheureusement lorsqu’il le faut vraiment, il n’y a qu’un flicage permanent qui peut les forcer à faire des tests, bien souvent sans conviction aucune.

Je n’ai pas le temps de tester

Parmi ceux qui voient un intérêt à écrire des tests, il y a ceux (et ils sont nombreux) qui n’ont pas le temps de le faire. C’est une super bonne excuse, aussi bien pour sa propre conscience que pour les autres.

Pourtant, je considère que lorsqu’on utilise l’expression « je n’ai pas le temps de […] » on peut la remplacer dans plus ou moins n’importe quel contexte par « je ne prends pas le temps de […] », ce n’est ni plus ni moins qu’un moyen de se mentir à soi-même de façon à garder bonne conscience. Si on l’applique aux tests, ça donne « je ne prends pas le temps de tester », et tout d’un coup, l’excuse est bien moins bonne.

Dire « je n’ai pas le temps de […] » est souvent témoin d’un manque de volonté. Cela signifie qu’il y a d’autres choses plus prioritaires. En réalité, quand on a vraiment envie de faire quelque chose, on trouve toujours le temps, aussi bien dans la vie professionnelle que dans la vie personnelle.

Et si vous êtes convaincu par l’intérêt des tests et que vos responsables ne vous laissent réellement pas le temps d’en écrire, demandez-vous si vous êtes bien à votre place à ce poste. Vous travaillez sans doute pour des gens qui ne vous laissent pas exercer votre métier correctement…

Je ne sais pas tester

Les courageux qui ont franchi les étapes précédentes butent souvent sur une difficulté qui n’est pas des moindres. Pourtant bien décidés à tester leur code, ils se retrouvent dans l’incapacité parfois totale à le faire parce qu’ils ne savent tout simplement pas le faire.

Je suis moi aussi passé par cette étape. Mais c’est loin d’être une fatalité. Tester, c’est comme coder, ça s’apprend. Et malheureusement on ne l’apprend pas beaucoup à l’école.

Écrire des tests suppose que le code à tester soit testable. Et en fait ce n’est pas du tout trivial. Comme j’ai pu déjà l’exprimer quand j’expliquais ce qui pour moi est un code de qualité, un bon code est entre autres un code testable. Et un bon moyen de parvenir à du code testable est de l’écrire proprement en respectant les bonnes pratiques telles que le principe de responsabilité unique par exemple.

Je conseille aux développeurs qui en sont à ce stade de commencer à tester du code nouveau pour ne pas subir la non testabilité. Et un bon moyen d’apprendre à tester, c’est de faire du TDD. Il faut pour cela trouver un cas d’application qui s’y prête bien, par exemple un algorithme avec des entrées et de sorties facilement descriptibles. Le fait d’écrire les tests avant le code implique intrinsèquement que le code associé soit testable. Cela permet d’apprendre à la fois comment tester et comment écrire du code testable.

Comme pour l’écriture de code applicatif, il existe des bonnes pratiques qui permettent d’écrire des tests utiles. Un test utile c’est un test qui s’exécute rapidement (feedback le plus rapide possible). C’est également un test qui, quand il échoue, indique à la fois la fonctionnalité concernée mais aussi de bons indices qui permettent  de comprendre la source du problème. C’est aussi un test qui va être capable de survivre aux futurs refactorings qui seront appliqués au code qu’il teste. Un bon test c’est également un test déterministe, pas un test qui dit noir une fois et blanc la fois suivante. Il y a eu cette année à Devoxx une très bonne conférence qui montre des astuces, des outils et des bonnes pratiques pour améliorer ses tests : Le bon testeur il teste…. et le mauvais testeur il teste aussi…

Je teste et j’ai confiance en mon code

Heureusement, de plus en plus de développeurs sont parvenus à ce stade, et je pense en faire partie. De la même manière qu’un alpiniste grimpe avec une corde, le testeur aguerri progresse avec assurance grâce aux tests. Pour ces gens-là, tester n’est plus une corvée. Je dirais même que ça peut parfois devenir un plaisir. Même si de bons tests ne protègent pas de tout, le testeur assidu retrouve une bonne confiance en ce qu’il livre, c’est quand même vachement agréable de ne pas avoir à croiser les doigts à chaque mise à jour de la prod !

Il arrive de devoir tester du code peu ou pas testable. Parfois même, on ignore tout de ce code, y-compris ce qu’il fait. Ce qui est quasiment une mission impossible pour un testeur en herbe peut se transformer en défi pour un testeur aguerri. Il existe une multitude de techniques pour se sortir de telles situations. Très souvent, cela va nécessiter du refactoring. On peut trouver sur internet de belles démonstrations en live coding de ces techniques, dont notamment celles de David Gageot et de Sandro Mancuso qui sont toutes les deux remarquablement bien présentées et très instructives.

Bien sûr, le bon testeur ne reste pas sur ses acquis. Il se forme continuellement, il suit l’évolution des outils, il a un regard critique sur ce qu’il a fait dans le passé dans l’objectif de s’améliorer continuellement. Il passe également du temps à évangéliser les tests et aide ses collègues à gravir les échelons.