Mocks aren't stubs - Développement piloté par les tests et doublures d’objets
Préface
Ce site est l'écho d'un exposé présenté devant la promotion 2013-2014 des apprentis ingénieurs en troisième année de la filière Informatique et Réseaux de l'ESIPE. Cet exposé s'inspire largement d'un célèbre article du blog de Martin Fowler, "Mocks aren't stubs". Ces pages web n'ont néanmoins pas pour but d'être une traduction de l'article. Il s'agit d'une synthèse ré-interprétée, proposant quelques éléments supplémentaires.
Introduction
En programmation, avant même de parler de code testé, il est bon de parler de code testable. La testabilité d'une architecture est une garantie d'un bon découplage entre les différents modules qui constituent le code source d'une application. Ce découplage, chers aux principes SOLID de la programmation orientée objet, est un gage de qualité.
Considérons tout d'abord qu'il n'y a que deux types de tests :
- Les tests unitaires qui vérifient le fonctionnement de la plus petite brique (une fonction, une méthode...)
- Les tests fonctionnels qui utilisent l'application comme le ferait l'utilisateur, pour réaliser des opérations de bout en bout du système, en vue d'en vérifier sa conformité fonctionnelle. Un exemple de scénario de test fonctionnel : je me connecte en tant qu'utilisateur et je n'ai pas accès à l'administration du site web
Concrètement, les test unitaires testent le code et les tests fonctionnels testent l'application. La testabilité du code concerne donc la simplicité (ou la complexité) d'écrire des tests unitaires pour le programme à tester.
Or, il y'a deux grandes manières d'écrire des tests unitaires :
- Les tests unitaires classiques
- Les tests unitaires utilisant des "doublures" à la place de certains objets
Les différences, les avantages et les inconvénients entre ces deux techniques, sont les pricipaux thèmes de ce site web. L'objectif : comprendre qu'écrire des tests n'est pas (uniquement) vérifier le fonctionnement de son code.