Depuis pas mal de temps, je me pose des questions sur les bonnes pratiques à mettre en œuvre dans le développement de mes tests unitaires. N’ayant jamais rencontré de personne ayant beaucoup d’expérience dans le domaine, je me suis toujours restreint à développer des tests :

• Rapides à développer
• Faciles à maintenir
• limités à une fonctionnalité

C’est dans ce contexte que j’ai cherché sur internet des propositions de bonnes pratiques sur les tests unitaires automatisés. J’ai trouvé mieux : des pratiques à éviter (http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/).

2 Responses to “Test unitaires : mauvaises pratiques (TDD anti-pattern)”

1. revo says:

   15/07/2011 at 10:49 pm

   C’est compliqué d’écrire des tests unitaires surtout si on ne nous donne pas le temps (pression du client), si l’équipe n’a pas envi d’écrire de tests (si on est le seul à écrire des tests dès qu’un autre développeur touche à notre code il ne touche pas à nos tests et c’est souvent à nous de les modifier) ou si on ne nous autorise pas à utiliser les outils kivonbien (EasyMock, Mockito).

   Reply
2. Yan says:

   16/07/2011 at 11:59 am

   C’est clair que les tests unitaires ne sont pas toujours évident à développer, surtout lorsque le temps est compté.
   Mais, je pense que sur les nouveaux projets, l’effort n’est pas si important que cela si :
   – Les développeurs acceptent de s’impliquer dans une démarche TDD (Test Driven Development)
   – Les outils de build intègrent des solutions de tests automatiques qui interdisent la création des livrables s’il y a des erreurs dans les tests (comme Maven par exemple).
   En effet, si un développeur pense en amont à tester son code, il adoptera, en général, des méthodes (ou astuces) de travail qui lui permettront de faire des tests simples et donc faciles et rapides à développer et à maintenir.
   En revanche, sur des projets déjà existants où il n’y a jamais eu de test automatisé, je confirme qu’il est très difficile de mettre en place une solution puis de la faire adopter à l’équipe.
   Sinon, dans les contextes les plus difficiles, la notion de mock partiel (Mokito et EasyMock le supportent) est peut-être une bonne idée pour commencer. Encore faut-il être autorisé à l’utiliser…

   Mais en règle générale c’est une démarche d’équipe qui doit être acceptée par l’ensemble des protagonistes (pas seulement les développeurs).

   Reply