De plus en plus présent. Mais cet outil est-il utilisé correctement ?

JUnit est un framework de tests unitaires. Son utilité n’est plus à prouver. Beaucoup de personnes l’utilisent, mais pas toujours de la bonne façon.

Ady nous fait découvrir deux articles sur les exemples à ne pas suivre lors de l’implémentation de tests unitaires. L’article de Joe Schmetzer intitulé JUnit Anti-pattern est très bien écrit et met en évidence les pièges à éviter. Selon l’auteur, il faut éviter d’écrire des tests :

  • sans assertions
  • avec plusieurs assertions
  • avec des assertions superflues
  • avec des assertions non-adaptées
  • avec des try/catch

Dans ces exemples, ce que l’on peut souvent rencontrer ce sont les try/catch. Beaucoup de développeurs ont pris l’habitude de gérer les exceptions dès qu’il est possible d’en rencontrer une[1]. Cependant lors de l’écriture de test unitaire, il est rarement nécessaire de gérer les l’exceptions[2]. Laissez l’exception remonter jusqu’au framework JUnit !

En revanche, J. Schmetzer explique qu’il ne faut pas mettre plusieurs assertions dans un même test. Il n’a pas tord puisque la première assertion en échec masque les suivantes. Pourtant dans la réalité, l’application de cette bonne pratique peut vite devenir un vrai calvaire. En effet, un simple test avec cinq ou six assertions doit être remplacé par cinq ou six fois le même test avec pour chaque test une assertion différente. Le nombre de tests à écrit est alors considérable.

Il ne faut pas négliger la qualité de l’écriture des tests unitaire. Gardez les précédentes recommandations en mémoire.

Notes

[1] C’est une bonne habitude dont il ne faut pas trop abuser.

[2] Sauf si justement le test doit vérifier qu’une exception est bien levée.