Mocks aren't stubs - Développement piloté par les tests et doublures d’objets
Conclusion
L'utilisation d'un style de TDD ou d'un autre est un choix strictement personnel. Les TDD classiques et orientés mocks ont chacun leurs règles et leurs impacts. Si l'on en prend connaissance et que l'on maîtrise ses outils (framework de mocking, API de tests unitaires), c'est la prise de recul qui générera la qualité de la conception. Il n'y a rien de magique dans aucune des techniques.
Le message à retenir de cet exposé et de ce site, n'est pas vraiment la différence entre les mocks et les stubs : elle est en réalite plus triviale qu'on ne le pense. La vraie morale de cette histoire, c'est que du code qui n'est pas testable est un code de mauvaise qualité, mal conçu et laborieux à reprendre. Nous sommes dans une ère où le développement logiciel doit avancer plus vite, les preuves en sont les efforts managériaux avec l'utilisation des méthodes agiles comme Scrum. L'agilité est censé permettre une haute adaptabilité au changement. Le code doit donc être maintenable, flexible, extensible : une application vit avec son code. La moindre modification de celui-ci doit être parfaitement contrôlé pour anticiper au mieux les bugs et corriger les régressions le plus rapidement possible. C'est pour cela qu'il est critique de choisir la méthode de test qui nous convient le mieux.