Cela vous permet de tester comment une partie de votre projet interagit avec le reste, sans tout construire et sans risquer de manquer une partie vitale.

EDIT : Excellent exemple de wikipedia : il vous permet de tester le code à l'avance, comme un concepteur de voiture utilise un mannequin de crash test pour tester le comportement d'une voiture lors d'un accident.

Un objet fictif vous permet de tester uniquement ce que vous écrivez et des détails abstraits tels que l'accès à une ressource (disque, service réseau, etc.). La simulation vous permet ensuite de faire semblant d'être cette ressource externe, ou classe ou autre.

Vous n'avez pas vraiment besoin d'un framework d'objets fictifs, étendez simplement la classe de la fonctionnalité dont vous ne voulez pas vous soucier dans votre test et assurez-vous que la classe que vous testez peut utiliser votre maquette au lieu de la vraie chose ( passez-le via un constructeur ou un setter ou quelque chose comme ça.

La pratique montrera quand les simulations sont utiles et quand elles ne le sont pas.

EDIT : se moquer des ressources est particulièrement important afin que vous n'ayez pas à vous fier à elles pour exister pendant le test, et vous pouvez vous moquer des détails de leur existence et de ce qu'elles répondent (comme la simulation d'une exception FileNotFoundException ou d'un service Web qui manque, ou diverses valeurs de retour possibles d'un service Web)... le tout sans les temps d'accès lents impliqués (la moquerie s'avérera BEAUCOUP plus rapide que l'accès à de telles ressources dans le test).

Une autre utilisation est qu'il vous permettra de tester d'autres parties de votre système qui ne sont pas encore construites. Par exemple, si votre classe dépend d'une autre classe qui fait partie d'une fonctionnalité sur laquelle quelqu'un d'autre travaille, vous pouvez simplement demander une interface presque complète, programmer l'interface et simplement simuler les détails comme vous vous attendez à ce qu'ils fonctionnent. Ensuite, assurez-vous que vos hypothèses concernant l'interface étaient correctes (soit pendant le développement, soit une fois la fonctionnalité terminée).

L'utilité ou non d'un framework de simulation dépend en partie du langage du code que vous écrivez. Avec un langage statique, vous devez déployer des efforts supplémentaires pour inciter le compilateur à accepter vos objets fictifs en remplacement de l'objet réel. Dans un langage à typage dynamique tel que Python, Ruby ou Javascript, vous pouvez généralement simplement attacher les méthodes à un objet ou à une classe arbitraire et le transmettre en tant que paramètre ; ainsi, un framework ajouterait beaucoup moins de valeur.