En lisant les articles et les blogs sur les tests unitaires, j’ai remarqué que généralement il existe une confusion entre les mocks et les stubs. Le sujet a été traité de nombreuses fois mais le vocabulaire utilisé avec les tests unitaires mélange souvent la notion du stub et du mock. Pour commencer je vous conseille de lire l’article qui est la référence en la matière. Il s’agit de Martin Fowler et de son article « Mock Aren’t Stubs ». Un petit rappel pour ceux qui ne connaissent pas trop les tests unitaires. Les mocks et les stubs sont les « faux » objets qui remplacent les vrais afin d’enlever la dépendance externe dans le système. En les utilisant vous pouvez tester votre code sans la dépendance directe. Mais cette définition est trop simpliste…

Sans rentrer dans les détails, la question que nous nous posons le plus souvent est la suivante : Quand est-ce que je dois utiliser le stub et quand le mock ?

A première vue la différence entre les mocks et les stubs paraît très petite ou même inexistante. Pourtant la manière dont l’information circule entre le SUT (System Under Test) et le test lui-même, n’est pas la même pour les stubs et les mocks. Personnellement je les utilise de la manière suivante :

  • Stub est centré sur le système testé (SUT). Il lui fourni une « indépendance » sous forme d’un objet véhiculant certaines données qui seront utilisées par le SUT pendant le test. Le stub ne peut jamais faire échouer le test. L’assertion est effectuée directement contre le SUT. Ceci s’appelle « state-based testing » car on vérifie juste l’état de notre SUT à la fin du test et non la manière dont cet état a été obtenu.
  • Mock est centré sur le test. Lors de la création du mock nous enregistrons un certain nombre d’attentes qui sont vérifiées pendant l’exécution du test. Le mock décide ci le test échoue ou réussi donc notre assertion nous la faisons contre le mock et non contre le SUT comme c’était dans le cas du stub. Dans le cas du mock ce n’est pas le résultat final qui nous intéresse mais la manière dont il a été obtenu ; Combien de fois une méthode a été invoquée ? Un évènement a été levé ? Qu’est-ce qu’il a été fait dans cette évènement ?, etc. Nous appelons ce cas « Interactions testing ».

J’ai essayé de faire un petit schéma pour mieux illustrer mes propos :

Mocks Stubs

Bons tests :)