De l’utilité des tests

Les tests nucléaires sont ils préalablement testés ?

Ca coûte trop cher ! Pourquoi forcer le client ? C’est trop long ! Je sais pas faire ! —Un développeur / patron / commercial / client de 9 projets sur 10

Je généralise beaucoup pour jouer la provocation. Que vous soyez développeur ou décisionnaire d’un projet, vous avez forcément à un moment ou à un autre de votre carrière rencontré cette fameuse problématique : est ce qu’il faut tester son code, et si oui jusqu’à quel point ? Comment ?

Préambule

Depuis maintenant 2 ans et demi que j’échange chez @Zol_Web mon temps libre contre des crédits pour pouvoir faire le plein de ma moto (un “salaire” pour “vivre” m’a t on dit), j’ai acquis auprès d’autres personnes qui y échangent aussi leur temps libre (certains pour le plein de leur trottinette) une certaine “confiance”. Plusieurs projets réussis, d’autre moins (faut être honnête avec soi même), et maintenant on me pose des questions du genre “Tu penses quoi de ça ?” ou encore “Tu ferais comment là ?”, et le sujet des tests revient très souvent (la citation exagérée façon click bait aussi d’ailleurs).

Je me suis dit que ce serait une bonne idée de partager mon point de vue directement sur les Internets, là où rien n’est oublié et tout est à portée de clic ! Enjoy !

Des “tests” ?

Entendons nous d’abord sur le terme. Il a surement déjà été décrit par des personnes bien plus compétentes que moi, je pense cependant qu’il est nécessaire qu’on soit tous sur la même longueur si on veut faire avancer le schmilblick.

J’entends par “test” tout procédé (automatique ou manuel) visant à assurer, après modification, qu’une partie (ou un tout) d’un système continue de produire le résultat attendu.

J’irai même plus loin dans l’idée en précisant ce que j’appelle par bug : tout procédé d’une partie d’un système ne produisant pas le résultat attendu. Cela peut bien sûr être dû à une erreur de code (division par 0, faute de frappe) mais aussi par exemple à deux fonctionnalités incompatibles : le test sert à détecter cet état (mieux vaut prévenir que guérir comme on dit).

Si on descend au niveau du développement web, on pourra donc citer les tests fonctionnels (behat), unitaires (phpunit), ou même manuels : le client qui teste en staging que ça correspond à ce qu’il a demandé, votre boss, vos collègues …

Toujours pour le développement web, l’avantage incroyable, c’est qu’on peut “automatiser” tout ce qu’on veut ! Je vous invite à vous renseigner sur des notions d’ “intégration continue” et de “déploiement continu”, vous allez voir c’est magique. Pas besoin de faire quoi que ce soit, dès qu’on modifie une fonctionnalité, on peut savoir en quasi live si on a cassé quelque chose.

Dur retour à la réalité

A lire ma définition des tests, on pourrait se dire “Mais … c’est que du bénef ça ! A fond sur les tests ! Testons tout partout tout le temps ! Qu’est ce qui pourrait mal se passer ?”

Eh bien, vous connaissez le dicton, l’enfer est pavée de bonnes intentions … Et croyez moi en terme de dev on est responsable de tronçons entiers d’autoroutes.

Dans la réalité (on y est tous soumis jusqu’à preuve du contraire), il y a plusieurs considérations à prendre en compte :

• Le temps que vous passez à écrire un test n’est pas gratuit (sinon c’est pas un échange équitable, vous donnez votre temps libre) : ça demande du temps (donc de l’argent !)
• Le monde bouge, les projets évoluent, et même les clients n’ont pas réponse à tout dès le premier jour du projet. Des blocs de code, des pages, des fonctionnalités entières peuvent disparaître du jour au lendemain.
• C’est pas tout le temps facile d’écrire des tests : vous êtes nouveau sur le domaine, vous dépendez d’API externes, vous avez pas accès à toutes les sources …
• Une dernière considération qui en fera peut être bondir quelques uns mais que j’assume entièrement : des fois les développeurs n’ont juste pas envie d’écrire des tests. Pourquoi je devrais mettre deux fois plus de temps pour livrer un code et être mal vu du client, du boss, des collègues parce que je suis plus long ?

Comme a dit un jour Shakespeare :

To test or not to test ? That is the question.

Mon avis sur le sujet

A bah quand même ! Alors !? Ca vaut le coup ou pas les tests ?

Je pense que la vrai question qu’il faut se poser c’est : quel risque j’accepte de prendre ?

En tant que développeur, est ce que j’accepte de prendre le risque que mon bout de code ne fonctionne pas un jour (et d’être mal vu de mes collègues) ?

En tant que boss d’une agence de dev, est ce que j’accepte de prendre le risque que la réputation de ma boîte (le fruit de mon travail) en prenne un coup parce que ça marche pas ?

En tant que client, est ce que j’accepte le risque qu’un utilisateur final soit frustré de ne pas pouvoir utiliser le site comme on lui a promis quitte à ce qu’il parte et ne revienne plus jamais ?

Les deux premières questions sont en réalité bien moins importantes que la dernière : ça arrive de faire des erreurs dans le code, mais c’est rarement la faute d’une seule personne; quant à la réputation de l’entreprise, c’est pas un ou deux bugs sur le site du client qui vont entacher sa réputation, mais plutôt la façon dont le problème va être réglé (et on rentre dans un tout autre domaine que cet article).

Pour les utilisateurs finaux d’un site, c’est une autre histoire : pensez vous qu’un utilisateur n’ayant pas pu s’inscrire sur la landing page à cause d’un bug reviendra réessayer dans quelques jours ? Bien évidemment, ce bug est apparu juste après le lancement du site, d’une campagne pub dans le métro, ou pire, d’un spot télé …

Je pense que la clé pour trouver la réponse à cette question cruciale est d’évaluer le coût de chaque erreur. D’aucuns parleront de la matrice des risques, je dirais que sans aller jusqu’à faire une étude poussée, il est aisé de repérer les parties critiques d’un système :

• Inscription utilisateur : c’est souvent la première étape, c’est déjà assez compliqué de trouver la bonne alchimie pour convaincre de s’inscrire, si on pouvait éviter les surprises …
• Processus de paiement : à partir du moment où on touche au porte monnaie de l’utilisateur, il devient primordiale de le rassurer par des mails de confirmation, des textes clairs … et sûrement pas une belle erreur 500 ! “Mon paiement est passé ? Est ce que je dois recommencer ? Je veux pas repayer mais j’ai vraiment envie d’assister à ce concert et il restait à peine 10 places !”
• …

Limiter les coûts des tests

Les tests ne sont pas non plus un bloc de granite géant : vous pouvez très bien commencer par des choses basiques telles que vérifier qu’une page s’affiche bien (renvoie une 200 et pas une 500), que le javascript ne comporte pas d’erreur …

Si vous travaillez en PHP, il existe des dizaines d’outils qui vous permettent de vérifier qu’il n’y a pas d’incohérence dans votre code (liste non exhaustive)

Savez vous que la commande php a un argument -l (linter) qui permet de vérifier la syntaxe de votre code ? Allez c’est cadeau :

find -L src -name '*.php' -print0 | xargs -0 -n 1 php -l

pour lancer la commande sur tous les fichiers du répertoire src .

Là où je veux en venir c’est que c’est facile de mettre en place quelques tests rapides permettant de se prémunir d’erreurs classiques. Sans que ce soit un gouffre financier ni une plaie à maintenir.

Et le client dans tout ça ?

Ne le mettez pas de côté. Au contraire. Déjà parce que c’est la première personne à pouvoir juger de ce qui est critique ou non sur son site, de plus c’est notre devoir de développeur (au sens général du corps de métiers) de l’aider à comprendre les enjeux de telles questions.

Si vous lui dites “Est ce que vous voulez qu’on écrive des tests pour notre code ?” sans info supplémentaire, dans le meilleur des cas il vous demande ce que ça implique en terme de coût, dans le pire des cas il pense tout savoir sur tout et répond “Pas la peine, je testerai avant de mettre en ligne”.

Par contre si la question est abordée sous l’angle des risques et des coûts engendrés, c’est difficile d’en ignorer les conséquences : “Est ce que vous pensez perdre moins d’argent si un bug se produit sur cette fonctionnalité ou si on passe une demi journée à écrire des tests dessus ?”

Conclusion

Il n’y a pas de honte à ne pas écrire de tests. Il n’y a pas non plus de honte à avoir un bug (pas trop non plus) dans son code. Ce qui est honteux, c’est de prendre un parti (rien tester ou tout tester) “par défaut”, “parce que j’ai toujours fais comme ça”, dans une gué-guerre qui n’aurait pas mis le projet au centre des intérêts. Posez vous les questions importantes avec le client : quelles sont les parties les plus critiques ? Quelles sont celles que je peux m’offrir le fait qu’elles ne fonctionnent pas le jour J ? Quels sont les risques que j’accepte de prendre ?