Tests unitaires et doublures de tests : les simulacres ne sont pas des bouchons

Le papier original en anglais est disponible ici.

Les exemples de cet article sont en Java, mais je les ai convertis en C#, (en utilisant par exemple NMock2, TypeMock) afin de rendre cet article plus facilement accessible à la communauté .NET.

Le vocabulaire anglais employé dans la littérature de test est assez délicat à traduire en français (et je suis d'ailleurs soulagé que Martin Fowler souligne que même en anglais ce vocabulaire est assez confus). J'ai suivi les traductions proposées ici. Donc la traduction utilise la table de correspondance ci-dessous :

Il y a plusieurs alternatives : objets fantaisie, mimes, etc.

Le mot stub est particulièrement vide de sens pour un francophone… Cette discussion au sujet de la traduction de to stub out est assez révélatrice.

En ce qui concerne la traduction de l'acronyme TDD (pour Test Driven Development), l'équivalent français DDT (Développement Dirigé par les Tests) n'est pas très parlant, ni très courant. Par conséquent TDD n'a pas été traduit. De même pour BDD (Behavior Driven Development) dont l'équivalent français serait DDC (Développement Dirigé par le Comportement). BDD n'a pas été traduit non plus.

Remerciements▲

J'ai rencontré pour la première fois le terme « objet simulacre » dans la communauté XP il y a quelques années. Depuis je les ai rencontrés de plus en plus. D'une part parce ce que beaucoup des principaux développeurs de ces objets ont fait partie de mes collègues à ThoughtWorks à différents moments. D'autre part parce que je les vois de plus en plus dans la littérature sur les tests influencée par XP.

Mais trop souvent je vois que les objets simulacre sont mal décrits. En particulier je les vois souvent confondus avec les bouchons – des utilitaires souvent employés dans les environnements de tests. Je comprends cette confusion – je les ai considérés comme similaires pendant un moment, mais des conversations avec les développeurs de simulacres ont fait régulièrement pénétrer un peu de compréhension des simulacres dans mon crâne de tortue.

Cette différence est en fait composée de deux différences distinctes. D'une part il y a une différence dans la vérification des tests : il faut distinguer vérification d'état et vérification de comportement. D'autre part il y a une différence de philosophie dans la manière dont le test et la conception interagissent, ce que je nomme ici par style « classique » et « orienté simulacre » du développement dirigé par les tests.

(Dans la version précédente de cet essai, j'avais réalisé qu'il y avait une différence, mais je combinais les deux. Depuis, ma compréhension s'est améliorée et il est temps de mettre à jour cet essai. Si vous n'avez pas lu le précédent essai, vous pouvez ignorer mes douleurs croissantes, car j'ai écrit cet essai comme si la précédente version n'existait pas. Mais si vous êtes familier avec la précédente version, vous pourriez trouver utile de noter que j'ai cassé la vieille dichotomie des tests basés sur l'état / tests basés sur l'interaction en deux dichotomies : celle de la vérification état/comportement et celle du style classique/orienté simulacre. J'ai également ajusté mon vocabulaire pour qu'il corresponde à celui du livre de Gerard Meszaros xUnit Test Patterns).

Je vais commencer par illustrer les deux styles avec un exemple simple (l'exemple est en Java, mais les principes sont valables pour n'importe quel langage orienté-objet). Nous voulons prendre un objet Commande (Order) et le remplir à partir d'un objet Entrepôt (Warehouse). La commande est très simple, avec un seul produit et une quantité. L'entrepôt contient les inventaires de différents produits. Quand nous demandons à une commande de se remplir elle-même à partir d'un entrepôt, il y a deux réponses possibles. S'il y a suffisamment de produits dans l'entrepôt pour satisfaire la commande, la commande est considérée remplie, et dans l'entrepôt la quantité de produits est réduite du montant approprié. S'il n'y a pas suffisamment de produits alors la commande n'est pas remplie, et rien ne se produit au niveau de l'entrepôt.

Ces deux comportements impliquent quelques tests, qui sont des tests JUnit assez conventionnels :

public class OrderStateTester extends TestCase {
  private static String TALISKER = "Talisker";
  private static String HIGHLAND_PARK = "Highland Park";
  private Warehouse warehouse = new WarehouseImpl();

  protected void setUp() throws Exception {
    warehouse.add(TALISKER, 50);
    warehouse.add(HIGHLAND_PARK, 25);
  }
  public void testOrderIsFilledIfEnoughInWarehouse() {
    Order order = new Order(TALISKER, 50);
    order.fill(warehouse);
    assertTrue(order.isFilled());
    assertEquals(0, warehouse.getInventory(TALISKER));
  }
  public void testOrderDoesNotRemoveIfNotEnough() {
    Order order = new Order(TALISKER, 51);
    order.fill(warehouse);
    assertFalse(order.isFilled());
    assertEquals(50, warehouse.getInventory(TALISKER));
  }

Note du traducteur : cet exemple est disponible en C# ici.

Les tests xUnit suivent une séquence typique de quatre phases : initialisation, exécution, vérification, nettoyage. Dans ce cas la phase d'initialisation est faite partiellement dans la méthode setUp (initialiser l'entrepôt) et partiellement dans la méthode de test (initialisation de la commande). L'appel à order.fill est la phase d'exécution. C'est là que l'objet est incité à faire la chose que nous voulons tester. Les déclarations assert sont ensuite la phase de vérification, elles contrôlent si la méthode exécutée a fait correctement son travail. Dans ce cas il n'y a pas de phase de nettoyage explicite, car le ramasse-miettes le fait implicitement pour nous.

Durant l'initialisation il y a deux sortes d'objets que nous mettons ensemble. Order est la classe que nous testons, mais pour que order.fill fonctionne, nous avons également besoin d'une instance de Warehouse. Dans cette situation Order est l'objet sur lequel nous focalisons le test. Les gens orientés-tests aiment utiliser des termes comme l'« objet en cours de test » ou le « système en cours de test » pour nommer une telle chose. Chacun de ces termes est difficile à dire, mais comme ils sont largement acceptés je me force à les utiliser. Suivant Meszaros j'utilise Système en cours de test, ou encore l'abréviation SCT.

Donc pour ce test j'ai besoin du SCT (Order) et d'un collaborateur (Warehouse). J'ai besoin de Warehouse pour deux raisons : d'une part pour faire fonctionner le comportement testé (puisque order.fill appelle les méthodes de warehouse) et d'autre part pour la vérification (puisqu'un des résultats de order.fill est un changement potentiel dans l'état de Warehouse). Au fur et à mesure que nous allons explorer ce sujet, vous allez voir que nous insisterons beaucoup sur la distinction entre le SCT et les collaborateurs (dans la version plus ancienne de cet article, je parlais du SCT comme l'« objet primaire » et des collaborateurs comme les « objets secondaires »).

Ce type de test utilise la vérification de l'état, ce qui signifie que nous déterminons si la méthode exécutée a fonctionné correctement en examinant l'état du SCT et de ses collaborateurs après l'exécution de la méthode. Comme nous le verrons, les objets simulacre permettent une approche différente de la vérification.

Maintenant je prends exactement le même comportement, mais j'utilise des objets simulacre. Pour ce code j'utilise la bibliothèque jMock pour définir les simulacres. jMock est une bibliothèque java pour les objets simulacre. Il y a d'autres bibliothèques pour objets simulacre, mais celle-ci est à jour et est développée par les créateurs de cette technique, donc c'est un bon point de départ.

public class OrderInteractionTester extends MockObjectTestCase {
  private static String TALISKER = "Talisker";

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    Mock warehouseMock = new Mock(Warehouse.class);
    
    //setup - expectations
    warehouseMock.expects(once()).method("hasInventory")
      .with(eq(TALISKER),eq(50))
      .will(returnValue(true));
    warehouseMock.expects(once()).method("remove")
      .with(eq(TALISKER), eq(50))
      .after("hasInventory");

    //exercise
    order.fill((Warehouse) warehouseMock.proxy());
    
    //verify
    warehouseMock.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    
    Mock warehouse = mock(Warehouse.class);
      
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());

    assertFalse(order.isFilled());
  }

Note du traducteur : cet exemple est disponible en C# ici.

Concentrez-vous d'abord sur le test testFillingRemovesInventoryIfInStock , car j'ai pris quelques raccourcis avec l'autre test.

Tout d'abord, la phase d'initialisation est très différente. Pour commencer, elle est divisée en deux parties : les données et les attentes. La partie données initialise les objets qui nous intéressent, et en ce sens elle est similaire à l'initialisation traditionnelle. La différence réside dans les objets qui sont créés. Le SCT est le même – une commande. Cependant le collaborateur n'est plus un entrepôt, mais un simulacre d'entrepôt – techniquement une instance de la classe Mock.

La deuxième partie de l'initialisation crée des attentes sur l'objet simulacre. Les attentes indiquent quelles méthodes devraient être appelées sur les simulacres quand le SCT est exécuté.

Une fois que les attentes sont en place, j'exécute le SCT. Après l'exécution je fais alors la vérification, qui a deux aspects. J'utilise des assertions sur le SCT – à peu près comme avant. Cependant je vérifie également les simulacres – en contrôlant qu'ils ont bien été appelés selon leurs attentes.

La différence clé ici est comment nous vérifions que la commande a fait ce qu'elle devait dans son interaction avec l'entrepôt. Avec la vérification d'état, nous faisons cela avec des assertions sur l'état de l'entrepôt. Les simulacres utilisent la vérification du comportement, et nous vérifions alors si la commande a fait les bons appels de méthodes sur l'entrepôt. Nous faisons cela pendant l'initialisation en disant au simulacre ce qu'il doit attendre, puis en demandant au simulacre de se vérifier lui-même durant la phase de vérification. Seule la commande est vérifiée à l'aide d'assertions, et si la méthode testée ne change pas l'état de la commande, alors il n'y a même pas d'assertions du tout.

Dans le deuxième test, je fais plusieurs choses différemment. Premièrement je crée le simulacre d'une autre manière, en utilisant la méthode mock dans MockObjectTestCase au lieu du constructeur. C'est une méthode utilitaire de la bibliothèque jMock, qui me permet d'éviter de faire explicitement la vérification plus tard ; en effet tout simulacre créé avec cette utilitaire est automatiquement vérifié à la fin du test. J'aurais pu faire cela avec le premier test aussi, mais je voulais montrer la vérification d'une manière plus explicite pour bien montrer comment fonctionne le test avec des simulacres.

Deuxièmement, dans le second test, j'ai relâché les contraintes sur l'attente en utilisant withAnyArguments. La raison est que le premier test vérifie déjà que le nombre est bien passé à l'entrepôt, aussi le deuxième test n'a pas besoin de répéter cet élément de test. Si la logique de la commande doit être modifiée plus tard, alors un seul test échouera, ce qui facilitera l'effort de migration des tests. J'aurais également pu laisser entièrement de côté withAnyArguments, car c'est le fonctionnement par défaut.

Utilisation de EasyMock▲

public class OrderEasyTester extends TestCase {
  private static String TALISKER = "Talisker";
  
  private MockControl warehouseControl;
  private Warehouse warehouseMock;
  
  public void setUp() {
    warehouseControl = MockControl.createControl(Warehouse.class);
    warehouseMock = (Warehouse) warehouseControl.getMock();    
  }

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    
    //setup - expectations
    warehouseMock.hasInventory(TALISKER, 50);
    warehouseControl.setReturnValue(true);
    warehouseMock.remove(TALISKER, 50);
    warehouseControl.replay();

    //exercise
    order.fill(warehouseMock);
    
    //verify
    warehouseControl.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    

    warehouseMock.hasInventory(TALISKER, 51);
    warehouseControl.setReturnValue(false);
    warehouseControl.replay();

    order.fill((Warehouse) warehouseMock);

    assertFalse(order.isFilled());
    warehouseControl.verify();
  }
}

Quand ils ont été introduits pour la première fois, beaucoup de gens ont facilement confondu les objets simulacre avec la notion courante de test avec des bouchons. Depuis ils semblent que les différences sont mieux comprises (et j'espère que la précédente version de cet article y a contribué). Cependant, pour comprendre complètement comment les simulacres sont utilisés, il est important de comprendre à la fois les simulacres et les autres types de doublures de tests (« doublures » ? Ne vous inquiétez pas si c'est un nouveau terme pour vous, attendez quelques paragraphes et tout deviendra clair).

Quand vous testez, vous vous focalisez sur un seul élément du logiciel à la fois – d'où le terme courant de test unitaire. Le problème est que pour faire fonctionner un élément particulier, vous avez souvent besoin d'autres éléments – par exemple dans notre exemple nous avons besoin de Warehouse.

Dans les deux types de tests que j'ai montrés ci-dessus, le premier type utilise un vrai objet Warehouse, et le deuxième utilise un simulacre de Warehouse, lequel bien sûr n'est pas un vrai objet Warehouse. Utiliser un simulacre est donc un moyen de ne pas utiliser un vrai Warehouse dans le test, mais d'autres formes de « faux » objets sont également utilisées.

Le vocabulaire pour parler de ces notions devient vite confus – toutes sortes de mots sont utilisés : bouchon, simulacre, substitut, fantôme. Pour cet article je vais suivre le vocabulaire du livre de Gerard Meszaros. Il n'est pas utilisé par tout le monde, mais je pense que c'est un bon vocabulaire, et comme il s'agit de mon article j'ai le privilège de choisir quels mots utiliser.

Meszaros utilise le terme Doublure de Test comme terme générique pour tout objet utilisé à la place d'un vrai objet dans le but de tester. Ce terme correspond au cascadeur qui double un acteur dans un film (un des buts de Meszaros était d'éviter tout nom déjà largement utilisé). Meszaros définit alors quatre types particuliers de doublures :

• Fantômes : des objets que l'on fait circuler, mais qui ne sont jamais réellement utilisés. Habituellement ils servent juste à remplir des listes de paramètres ;
• Substituts : des objets qui ont de véritables implémentations qui fonctionnent, mais qui généralement prennent des raccourcis qui les rendent impropres à l'utilisation en production (un bon exemple est une base de données en mémoire au lieu d'une vraie base de données) ;
• Bouchons : ces objets fournissent des réponses prédéfinies à des appels faits durant le test, mais généralement ne répondent à rien d'autre en dehors de ce qui leur a été programmé pour le test. Les bouchons peuvent aussi enregistrer de l'information concernant les appels, par exemple un bouchon de passerelle de courriels peut mémoriser les messages qu'il a « envoyés », ou encore seulement le nombre de messages qu'il a « envoyés » ;
• Simulacres : les objets dont nous parlons ici: des objets préprogrammés avec des attentes, lesquelles constituent une spécification des appels qu'ils s'attendent à recevoir.

Parmi toutes ces doublures, seuls les simulacres insistent sur la vérification du comportement. Les autres doublures peuvent (et généralement le font) utiliser la vérification d'état. En fait les simulacres se comportement vraiment comme les autres doublures dans la phase d'exécution, car ils ont besoin de faire croire au SCT qu'il parle à ses vrais collaborateurs – mais les simulacres diffèrent dans les phases d'initialisation et de vérification.

Pour explorer un peu plus les doublures de test, nous devons étendre notre exemple. Beaucoup de gens utilisent une doublure uniquement si le vrai objet est peu pratique à manipuler. Ici, disons que nous voulons envoyer un courriel si un Order échoue. Le problème est que nous ne pouvons pas envoyer de vrais courriels à des clients pendant nos tests. Donc à la place nous créons une doublure de notre système de courriels, que nous pouvons contrôler et manipuler.

Nous pouvons alors commencer à voir la différence entre les simulacres et les bouchons. Pour tester ce comportement d'envoi de courriels, nous pourrions écrire un simple bouchon comme ceci :

public interface MailService {
  public void send (Message msg);
}

public class MailServiceStub implements MailService {
  private List<Message> messages = new ArrayList<Message>();
  public void send (Message msg) {
    messages.add(msg);
  }
  public int numberSent() {
    return messages.size();
  }
}

Nous pouvons alors utiliser la vérification d'état sur le bouchon comme suit :

class OrderStateTester...
  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();
    order.setMailer(mailer);
    order.fill(warehouse);
    assertEquals(1, mailer.numberSent());
  }

Bien sûr c'est un test très simple – il vérifie seulement qu'un message a été envoyé. Nous n'avons pas testé qu'il a été envoyé à la bonne personne ni qu'il avait le bon contenu, mais il suffira à illustrer mon propos.

En utilisant des simulacres, ce test serait bien différent :

class OrderInteractionTester...
  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    Mock warehouse = mock(Warehouse.class);
    Mock mailer = mock(MailService.class);
    order.setMailer((MailService) mailer.proxy());

    mailer.expects(once()).method("send");
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());
  }
}

Dans les deux cas, j'utilise une doublure de test à la place du vrai service de courriel. La différence est dans le fait que le bouchon utilise la vérification d'état alors que le simulacre utilise la vérification du comportement.

Pour utiliser la vérification d'état sur le bouchon, j'ai besoin de quelques méthodes supplémentaires sur le bouchon pour faciliter la vérification. Par conséquent le bouchon implémente MailService, mais ajoute des méthodes de test supplémentaires.

Les simulacres utilisent toujours la vérification du comportement, tandis qu'un bouchon peut faire les deux. Meszaros nomme les bouchons qui utilisent la vérification de comportement comme des Espions de Test. La différence réside dans la manière dont la doublure effectue exécution et vérification, et je vous laisse le soin d'explorer cela vous-même.

Maintenant j'en suis au point où je peux explorer la deuxième dichotomie entre le test classique et orienté simulacre. Le point principal est quand utiliser un simulacre (ou une autre doublure).

Le style classique de TDD consiste à utiliser de vrais objets si possible, et une doublure quand le vrai objet est trop compliqué à utiliser. Ainsi un adepte du TDD classique utiliserait le vrai Warehouse et un double pour le service de courriels. Le type exact de doublure ne compte pas tant que cela.

Un adepte du style orienté simulacre, par contre, utilisera toujours un simulacre pour tout objet ayant un comportement intéressant, et donc dans ce cas pour la à la fois Warehouse et le service de courriels.

Bien que les différents outils de création de simulacres aient été conçus avec le style orienté simulacre en tête, beaucoup d'adeptes du style classique les trouvent utiles pour créer des doubles.

Une conséquence importante du style orienté simulacre est le Développement Dirigé par le Comportement (BDD). Le BDD a été initialement développé par mon collègue Dan North comme une technique pour aider les gens à mieux apprendre le Développement Dirigé par les Tests en insistant sur la technique de conception que représente le TDD. Cela a conduit à renommer les tests en comportements pour mieux explorer comment le TDD aide à réfléchir à ce qu'un objet doit faire. Le BDD suit une approche orientée simulacre, mais il va plus loin, à la fois dans ses styles de nommages, et dans son désir d'intégrer la conception dans sa technique. Je ne vais pas plus loin ici, car le seul lien avec cet article est que le BDD est une autre variation du TDD qui tend à utiliser les simulacres. Je vous laisse suivre le lien pour plus d'informations.

Dans cet article j'ai expliqué deux différences : vérification de l'état ou du comportement, style classique ou orienté simulacre. Quels sont les arguments à garder l'esprit quand on fait un choix entre ces styles ? Je vais commencer par le choix entre la vérification de l'état ou du comportement.

La première chose à considérer est le contexte. Pensons-nous à une collaboration facile, comme entre Order et Warehouse, ou une compliquée, comme entre Order et le service de courriels ?

Si c'est une collaboration facile alors le choix est simple. Si je suis un adepte du style classique, je n'utilise pas de simulacre, bouchon ou autre sorte de doublure. J'utilise le vrai objet et la vérification d'état. Si je suis un adepte du style orienté simulacre, j'utilise un simulacre et la vérification du comportement. Pas de décision à prendre du tout.

Si c'est une collaboration compliquée, il n'y a pas de décision si je suis un adepte des simulacres – j'utilise juste des simulacres et la vérification du comportement. Si je suis un adepte du style classique, alors j'ai le choix, mais il n'est pas bien important. Habituellement les adeptes du style classique décident au cas par cas, en utilisant le chemin le plus rapide pour chaque situation.

Donc comme nous le voyons, la décision entre vérification de l'état ou du comportement n'est pas une grosse décision la plupart du temps. La vraie difficulté est de choisir entre TDD classique et orienté simulacre. Il apparaît que les caractéristiques de la vérification de l'état et du comportement affectent cette discussion, et c'est là que je vais focaliser mon énergie.

Mais avant de le faire, je vais proposer un cas limite. De temps en temps vous rencontrez des choses dont il est vraiment difficile de vérifier l'état, même s'il ne s'agit pas de collaborations compliquées. Un bon exemple de cela est un cache. La particularité d'un cache est que vous ne pouvez pas dire à partir de son état comment le cache a fonctionné – c'est un cas où la vérification du comportement serait un choix sage même pour un adepte pur et dur du style TDD classique. Je suis sûr qu'il y a d'autres exceptions dans les deux directions.

Maintenant que nous approfondissons le choix entre styles classique/orienté simulacre, il y a des tas de facteurs à considérer, donc je les ai organisés en groupes grossiers :

Le guidage du TDD▲

L'initialisation des classes de test▲

L'isolation des tests▲

Le couplage des tests avec les implémentations▲

Le style de conception▲

Je trouve qu'il est difficile de répondre avec certitude. Personnellement j'ai toujours été un adepte du bon vieux TDD classique et jusque-là je ne vois pas de raison de changer. Je ne vois aucun bénéfice irréfutable pour le TDD avec simulacres, et je suis préoccupé par les conséquences de coupler les tests avec l'implémentation.

Ceci me frappe particulièrement quand j'observe un programmeur orienté simulacre. J'aime vraiment le fait que pendant que vous écrivez le test, vous vous concentrez sur le résultat du comportement, pas sur comment il est fait. Un adepte des simulacres réfléchit constamment à l'implémentation du SCT pour pouvoir écrire les attentes. Cela me paraît vraiment antinaturel.

Je souffre également de l'inconvénient de ne pas essayer le TDD avec simulacres sur autre chose que des applications jouets. Comme je l'ai appris du TDD lui-même, il est souvent difficile de juger une technique sans l'essayer sérieusement. Je connais beaucoup de bons développeurs qui sont des adeptes convaincus et très heureux des simulacres. Donc bien que je sois toujours un classique convaincu, j'ai préféré présenter les deux arguments aussi équitablement que possible de telle sorte que vous puissiez vous faire votre propre idée.

Donc si le test avec simulacres vous paraît attractif, je vous suggère de l'essayer. Cela en vaut particulièrement la peine si vous avez des problèmes dans certaines zones que le test avec simulacre est conçu pour améliorer. Je vois deux zones principales ici. La première si vous passez beaucoup de temps à déboguer quand des tests échouent, parce qu'ils n'échouent pas proprement et ne vous disent pas où est le problème. La deuxième si vos objets ne contiennent pas suffisamment de comportements ; le test avec simulacres peut encourager l'équipe de développement à créer des objets plus riches en comportements.

Au fur et à mesure que grandit l'intérêt pour les outils xUnit et le Développement Dirigé par les Tests, de plus en plus de gens croisent les simulacres. Le plus souvent, ils apprennent une partie des outils pour simulacres, sans comprendre complètement la division classique/orienté simulacre sur lesquels ils reposent. Quelque soit votre côté dans cette division, je pense qu'il est utile de comprendre cette différence de vue. Alors que vous n'avez pas besoin d'être orienté simulacre pour trouver pratiques les outils de simulacre, il est utile de comprendre le raisonnement qui guide la plupart des décisions de conception du logiciel.

Le but de cet article était, et est toujours, de souligner ces différences et d'exposer les compromis entre elles. Il y a plus dans la réflexion orientée simulacre que ce que j'ai eu le temps d'approfondir, en particulier ses conséquences sur le style de conception. J'espère que dans les toutes prochaines années nous verrons plus de choses écrites sur cela, et que cela approfondira notre compréhension des conséquences fascinantes de l'écriture de tests avant le code.

Pour une revue complète de la pratique du test unitaire avec xUnit, gardez un œil sur le livre Gerard Meszaros qui va sortir (avertissement : il est dans mes séries). Il maintient aussi un site web avec les patrons du livre.

Pour en savoir plus sur le TDD, il faut commencer par le livre de Kent.

Pour en savoir plus sur le style de test orienté simulacre, le premier endroit à visiter est le site mockobjects.com où Steve Freeman et Nat Price recommandent le point de vue orienté simulacre avec des papiers et un bon blog. Lisez en particulier l'excellent papier OOPSLA. Pour plus d'informations sur le Développement Dirigé par le Comportement, une variante du TDD très orientée simulacre, commencez par l'introduction de Dan North.

Vous pouvez aussi en savoir plus sur ces techniques en allant voir les sites web des outils jMock, nMock, EasyMock, EasyMock.net (il y a d'autres outils disponibles, ne considérez pas cette liste comme complète).

Le papier original sur les objets simulacre a été présenté à XP2000, mais il est un peu dépassé maintenant.