Blog Xebia France

Les 10 commandements des tests unitaires

Les tests unitaires ne sont pas qu’une bonne pratique des méthodes agiles, ils sont un véritable pré-requis à la mise en place d’un développement itératif.
Le refactoring et la modification d’une base de code existante, bien que facilités par les environnements de développement actuels, comportent un évident risque de régression, en partie couvert par les tests unitaires.

Vous trouverez ci-dessous nos 10 commandements des tests unitaires.

1. Un test unitaire doit être véritablement unitaire. La classe testée doit l’être en isolation complète, afin de ne tester qu’une classe (et une méthode) à la fois, le SUT (System Under Test).
2. Si une classe est difficile à tester, il est temps de faire du refactoring. Est-elle trop volumineuse ? Présente-t-elle trop de dépendances ? Profitez de l’occasion pour la découper et déplacer du code dans des classes annexes.
3. Un test unitaire doit s’exécuter le plus rapidement possible afin d’avoir un retour quasi immédiat. Il faut donc proscrire l’accès à des fichiers, des bases de données ou des services externes dans un test unitaire. Un test qui dialogue avec une base de données n’est pas un test unitaire, c’est un test d’intégration.
4. Le code d’un test unitaire fait partie du code applicatif. Il doit donc, à l’image du reste de l’application, respecter des conventions de code. Chouchoutez vos tests unitaires, faites du refactoring sur leur code, respectez les bonnes pratiques, présentez le code à vos collègues, codez les tests en pair programming, sans quoi on trouvera certainement dans votre application des tests smells, des tests unitaires peu lisibles et difficilement maintenables. De bons tests unitaires doivent permettre à leur lecture de comprendre le comportement du SUT.
5. Isolez les dépendances de la classe testée grâce à l’injection de dépendances.
6. Ne testez qu’un comportement à la fois. Soyez raisonnable et gardez le test simple, lisible et concentré sur ce comportement.
7. Pensez à utiliser un framework de mocks pour injecter les dépendances sous forme de bouchons. Ces outils permettent de respecter le commandement n°1. Ne bannissez pas pour autant les bouchons codés à la main ; ils peuvent parfois rendre le test unitaire plus simple et plus lisible qu’avec un mock provenant d’un framework.
8. Identifiez précisément les étapes setup, exercise, verify, teardown dans votre code. On retrouve ces quatre étapes dans tout test unitaire.
9. Ne vous concentrez pas sur une couverture de code à 100%. Ce n’est qu’un indicateur technique, qui doit être examiné dans le contexte de l’application, et qui ne prouve en rien la qualité du code et des tests unitaires.
10. Ne développez pas vos tests unitaires « plus tard ». Si vous n’utilisez pas l’approche TDD, développez-les le plus tôt possible.

Les deux premières règles sont incontournables.

Ne tester qu’une classe à la fois facilite la maintenance et la correction des tests unitaires, et permet de se concentrer sur le comportement de la classe à tester. Quand un test unitaire échoue, on sait exactement d’où provient l’erreur (elle est soit dans le test unitaire si le comportement du SUT a changé, soit une modification du SUT a cassé son comportement attendu).

Si vous développez votre code sans penser aux tests unitaires que vous ferez « plus tard », il sera difficilement testable et vous perdrez un temps précieux pour corriger les erreurs de design. « Design for testability », en particulier, utilisez au maximum l’injection de dépendances, qui est obligatoire pour l’injection des bouchons. Si vous utilisez Spring ou un autre framework d’injection de dépendances, cela ne devrait pas être trop compliqué …

Pour aller plus loin, nous vous recommandons vivement la bible xUnit Test Patterns, de Gerard Meszaros, dans laquelle vous retrouverez une présentation sur l’automatisation des tests, un catalogue de « test smells », et une liste complète de « test patterns », des meilleures pratiques de tests unitaires qui ont émergé ces dernières années.

Enfin, vous trouverez également sur les blogs suivants une liste de commandements:

• 10 rules of (unit) testing de Szczepan Faber, auteur du nouveau framework de Mocks qui monte, Mockito
• Ten T.D.D. Commandments de Cliff
• Ten commandments of unit testing de Merlyn Albery-Speyer
• Ashcroft – Ten Commandments of Unit Tests de Aslak Hellesøy et Shane Duan, une des premières tentatives sur le sujet, hélas interrompue après le quatrième commandement.