Je ne sais pas pourquoi ces derniers temps, j'entend pas mal de retours comme quoi le refactoring serait ralenti par les tests unitaires. L'explication derrière cette affirmation douteuse est qu'il faut bien souvent modifier les tests en même temps que le code de production.
J'ai tendance à croire que cette idée bizarre est née d'une des deux écoles de TDD. Ces deux approches ont été bien décrites par Martin Fowler dans son article sur les mocks et les stubs.
Je vais me permettre de le paraphraser ici :
- L'approche classique essaye d'utiliser le plus possible de vrais objets, et un "double" s'il est difficile ou gênant d'utiliser l'implémentation réelle (par exemple, l'envoie d'un mail)
- L'approche par Mock va utiliser dans tous les cas des doubles de test pour tout objet ayant un comportement intéressant.
Pour qualifier ces deux méthodes, Mister Fabien parle de tests Boîte Noire et de tests Boîte Blanche.
Appliquer systématiquement une approche par mock implique une chose : on teste plus la chorégraphie de notre objet que ses résultats. Nous allons vérifier que tel méthode de tel mock a été appelé avec tel paramètre, et que si nous retournons tel valeur, alors notre objet va se comporter de telle manière. Ce faisant, nous liions inexorablement notre test avec l'implémentation sous-jacente, rendant par la même plus douloureux le refactoring, car il nous faudra effectivement changer les tests en même temps que le code de production. L'écriture des tests peut être fastidieux en plus, vu la quantité d'éléments à doubler (constat fait par exemple lors du JUG Bordelais sur le sujet
Dans une approche classique, comme nous testons la plupart du temps le comportement extérieur, nous nous moquons éperdument de l'implémentation, pour vu que le résultat soit bon, et nous passons également moins de temps à écrire nos doubles.
