[BuildStuff 2015] Good unit testing

A l’occasion de l’événement BuildStuff 2015 en Lituanie, à Vilnius plus précisément, j’ai eu l’occasion d’assister à la conférence de Kevlin Henney ayant pour thème « Programming with GUT(s) ».

Good Unit Testing (GUT)

Réussir à faire un assert avec l’outil de votre choix n’est que le début, et c’est bien là que ce situe la tâche la moins complexe.
Il ne s’agit pas plus d’avoir 100% de couverture de code ou de faire du Test Driven Development pour que les tests soient efficaces.

Durant ce billet, nous allons parcourir plusieurs petites étapes afin de rédiger de bons tests unitaires.

Pourquoi faire des tests ?

Vous ne voulez pas vous retrouver avec des bugs en production :

Ont-ils vraiment besoin de payer avec Paypal ?

Le mot du jour est assez sympathique comme cela

Red, Green, Refactor

Cet adage, bien connu dans le milieu du Test Driven Development, nécessite d’être bien compris avant d’être appliqué.

Kevlin nous a fait part du témoignage d’un membre de son équipe qui lui disait que parfois, il ne trouvait rien à refactoriser, du coup il changeait un peu le code et il le remettait comme il était après.

En outre, le fait de refactoriser n’est pas une fatalité. Parfois, il s’avère que le code est déjà propre et il n’y aurait pas de valeur à passer du temps et se creuser la tête pour le factoriser davantage.

Test Driven Development <> Good Unit Testing

Kevlin nous racontait une anecdote d’une équipe lui disant qu’ils faisaient de bons tests puisqu’ils codent en TDD et que c’est ce qu’il y a de mieux en matière de tests.

Bien que la TDD soit une pratique très puissante pour penser le code à implémenter avant de le produire et pour s’assurer que l’application est entièrement couverte, faire de la TDD n’implique pas de réaliser de bons tests.

Elle implique simplement de réaliser les tests en premier.

Clarté des tests

Vos tests doivent être explicites de par leurs noms, mais également de par leur contenu. Ce que vous voulez tester doit être clair, limpide, concis, pas comme ceux-là :
 
En suivant ces exemples, vous obtiendrez probablement un travail pour la vie à créer tous ces tests.

Un test doit échouer pour exactement une raison

C’est pour cela qu’un test ne doit pas vérifier plusieurs comportements via plusieurs Assert, voire doit vérifier une seule exception attendue.

Attribut Ignore

Cet attribut signifie la fin du cycle de vie d’un test, celui-ci deviendra tout au mieux un zombie.
Pour rappel, cet attribut, placé au dessus d’une méthode de test, indique à l’outil de test de ne pas vérifier celui-ci, il est généralement utilisé lorsqu’un test ne passe pas la barrière de l’intégration et qu’il est perçu comme étant trop complexe pour être modifier.
Avec généralement, la bonne intention de le « modifier plus tard », ce qui arrive, environ, jamais.

Assertion définitive

Un test doit vérifier un comportement, une action, il ne doit pas « vérifier que peut-être c’est ok ».
Un test doit être définitif, il ne doit pas comporter d’hésitation, on retrouve souvent par abus « Should » devant un test, voire « Works » :

Ne jamais répéter la logique testée

Votre test doit vérifier le résultat attendu, si vous avez besoin de découper en plusieurs tests votre fonction, faites plusieurs méthodes, mais un test ne doit pas contenir de logique.

Couverture de code

La couverture de code, peut être indicative d’une certaine qualité, si elle est de 0% ou de 10% par exemple, vous pouvez en déduire assez rapidement qu’il manque quelque chose à votre application.
Cependant, celle-ci ne signifie pas que votre application ne rencontrera pas de problèmes, elle indique juste qu’il y a des tests qui référencent vos fonctions, pas qu’ils le font bien, et c’est souvent le font du problème.

En soit

Il ne faut pas tester pour tester, un bon test implique souvent d’avoir bien pris le temps de réfléchir avant de l’écrire.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s