Comment puis-je supprimer les dépendances au code d'un tiers lors du test unitaire?

Question

J'ai du code qui effectue une opération de base de données héritée, puis traite le résultat. Je veux écrire un test unitaire qui vérifie la méthode qui appelle le code existant sans interagir avec la 'base de données'.

Mon code ressemble à ceci:

public static bool CallRoutine(LegacySession session, /* routine params*/) 
    { 
     try 
     { 
      LegacyRoutine routine = session.CreateRoutine(/* routine params */); 

      routine.Call(); 

      // Process result 

     } 
     catch (LegacyException ex) 
     { 
      // Perform error handling 
     } 
    } 

Si cela était tout mon code, je créerais des interfaces que le LegacySession et LegacyRoutine implémentent puis écrire des tests unitaires qui utilisent des implémentations simulacres de ces interfaces en utilisant MOQ ou quelque chose similaire. Le problème est que je n'ai pas accès au code pour LegacyRoutine ou LegacySession donc je ne peux pas les faire implémenter une interface.

Des idées sur comment je pourrais faire cela sans trop changer le code de production?

Answer 1

Si vous ne pouvez pas accéder à LegacyRoutine (je devine qu'il est dans une DLL de référence), pourquoi ne pas simplement créer une enveloppe pour, puis Flick on/off différentes implémentations:

public interface ILegacyWrapper 
{ 
    ILegacyRoutine CreateRoutine(); 
    // etc etc 
} 

public interface ILegacyRoutine 
{ 
    // put members of LegacyRoutine 
} 

Savoir ce que je veux dire? Juste se moquer de tout dans des enveloppes/interfaces.

Ensuite, vous pouvez aller:

ILegacyRoutine routine = session.CreateRoutine(/* routine params */) 

Où séance serait déclarée comme ILegacyWrapper, mais mis en œuvre avec un béton maquette.

En outre, il va sans dire (mais je le dis de toute façon), vous devriez envisager un cadre DI pour vous simplifier la vie. Sinon, vous finirez par IFoo foo = new Foo() (injection codée en dur) partout.

StructureMap est mon poison DI de choix.

HTH

Answer 2

Vous pouvez écrire une enveloppe fine sur leur API pour laquelle avait une interface. Que ce soit une chose pratique à faire ou non dépend plutôt de la taille de l'API.

Answer 3

Recherche de types de béton simulés C#. Désolé, je dois courir, mais voici un lien vers la première chose que je trouve cela résoudre votre problème (il peut y avoir de meilleures solutions, mais cela semble OK):

http://docs.typemock.com/isolator/##typemock.chm/Documentation/CreatingFakesWithAAA.html

Aussi, consultez Moq, avec qui j'ai eu beaucoup de succès dans le passé

Answer 4

Je vous conseille d'utiliser un cadre d'injection de depedency. Il vous aide à faire en sorte que vos classes soient plus librement copiées en séparant les dépendances de classes externes en objets qui sont injectés dans vos classes. Ces objets sont souvent représentés par une interface, ce qui vous aide à utiliser différentes implémentations en production et lors des tests. De cette façon, vous n'aurez pas besoin d'appeler la base de données externe lors des tests. Je peux recommander Ninject. Cela rend l'injection de dépendance beaucoup plus facile que de le faire manuellement.