dépendances Isoler sans inversion de contrôle

Question

Je travaille sur une application d'entreprise qui repose en grande partie sur les files d'attente de messages, com +, bases de données, HttpContext, classes utilitaires statiques, etc.

Comme il y a 600 projets dans notre système, il semble impossible de réécrire pour utiliser l'inversion de contrôle. Typemock prétend qu'ils sont le seul cadre d'isolement que doesn't require you to rewrite your code to use IOC.

Est-ce que quelqu'un sait comment TypeMock a implémenté ce niveau de fonctionnalité et s'il existe des alternatives? Même si je devais réécrire mon application pour utiliser l'inversion de contrôle, je devrais écrire des classes wrapper pour les files d'attente de messages, httpcontext etc. Pour moi cela semble ridicule, ai-je tort ou raison de penser que Typemock est la seule option viable? scénario.

Merci

Answer 1

Vous avez raison de penser que TypeMock (ou un autre outil de simulation similaire) est la seule option viable.

Il est toujours possible d'utiliser un outil AOP directement pour isoler les dépendances, mais l'effort requis pour le faire est important, ce qui le rend inutilisable en pratique.

Pour Java, le toolkit JMockit permet d'isoler tous les types de dépendances, sans apporter les modifications nécessaires au code de production.

En interne, JMockit utilise les fonctionnalités fournies par l'API java.lang.instrument. Fondamentalement, il permet aux méthodes/constructeurs d'être redéfini lors de l'exécution. Redéfinition signifie que le bytecode implémentant la méthode/constructeur est remplacé. Cela peut être fait n'importe quel nombre de fois pour la même méthode. De plus, les classes peuvent être transformées au moment du chargement (c'est-à-dire que toute méthode ou tout constructeur défini dans la classe peut avoir son bytecode modifié juste avant que la classe soit rendue disponible à la JVM).

Answer 2

Mocking non-virtual methods in C#

Sans creuser très profond, la réponse est des techniques AOP. Puisque vous pouvez intercepter des appels de méthode ou modifier des appels de méthode après le fait, cela rend très possible l'ajout de classes/instances fictives.

C'est une utilisation intelligente de l'AOP.

Si vous voulez faire sur votre propre (et je suis sûr qu'il ya des pièges ...), saisir un framework open source tisserand Aspect: http://csharp-source.net/open-source/aspect-oriented-frameworks

Answer 3

La plupart des cadres moqueurs ne reposent sur une certaine forme de CIO. C'est parce que la COI est en fait une bonne pratique. Mis à part le test, imaginez que vous avez une classe qui recherche une connexion à une base de données (plutôt que de l'injecter), et maintenant la classe de connexion à la base de données change. Vous ne devriez pas avoir à recompiler votre code - vous devriez juste pouvoir changer la dépendance injectée. Du point de vue des tests, vous pouvez faire la même chose, injecter un faux service de base de données.

Pour en savoir plus sur votre question. Je me concentrerais sur refactoring progressivement à une injection au lieu d'un cadre de recherche codé dur. Commencez par les grandes pièces, comme les bases de données et autres services tiers. Au fur et à mesure que vous les retravaillez, vous pouvez utiliser n'importe quel framework fictif (j'ai utilisé EasyMock et je l'aime, mais il y en a d'autres - JMock, Mockito). Ces frameworks ne nécessitent pas de classes wrapper, mais s'appuient généralement sur des objets proxy. Lorsque vous créez un faux, vous créez réellement un proxy (qui est une instance du type de classe que vous vous moquez).

La manipulation de code-octet (aspect orienté par exemple, comme l'utilise Typemock) peut être dangereuse sur laquelle s'appuyer. Il arrive souvent que vous ayez d'autres outils qui manipulent également du code octet (les outils de couverture de code le font souvent) et les manipulations multiples du bytecode peuvent provoquer un comportement inattendu.

Enfin, vous pouvez regarder des langues comme Groovy. Groovy fonctionne bien avec Java (il se compile en bytecode) et se moque de la langue. Certaines recherches de Google pour les objets simulés avec Groovy devraient retourner de bons résultats.

Answer 4

Si vous avez une classe comme ceci:

public class MotherClass 
{ 
    private SubClass _subClass; 

    public MotherClass() 
    { 
     _subClass = new SubClass(); 
    } 
} 

public class SubClass 
{ 
    public string SomeMethod() 
    { 
     return "Hello"; 
    } 
} 

Il est sans IoC. Mais avec Typemock Isolateur vous pouvez toujours le remplacer par:

[TestMethod] 
    public void TestMethod() 
    { 
     var fake = Isolate.Fake.Instance<SubClass>(); 
     Isolate.Swap.NextInstance<SubClass>().With(fake); 
    } 

et échangez même le résultat de la SomeMethod comme ceci:

 var fake = Isolate.Fake.Instance<SubClass>(); 
     Isolate.WhenCalled(() => fake.SomeMethod()).WillReturn("Bye");