Implémentation d'objets moqueurs avec Moq lorsque le constructeur a des paramètres

La meilleure chose à faire serait de droite, cliquez sur votre classe et choisir Extraire de l'interface.

Je vais traiter ce concept dans un sens orthogonal. Je suis en désaccord avec cette déclaration, une interface n'est pas la solution à la situtation en question.

Revenir à la question précédente du texte:

public class CustomerSyncEngine {
    public CustomerSyncEngine(ILoggingProvider loggingProvider, 
                              ICrmProvider crmProvider, 
                              ICacheProvider cacheProvider) { ... }

    public void MethodWithDependencies() {
        loggingProvider.Log();
        crmProvider.Crm();
        cacheProvider.Cache();
    }
}

Remarque la méthode que j'ai ajoutée.

Je crois que la vraie question, c'est quand vous n'êtes pas à tester CustomerSyncEnginemais plutôt de tester une classe qui dépend sur CustomerSyncEngine. Appelons cette classe SuperSyncEngine. La création d'un test contre SuperSyncEngine va être une douleur depuis que vous avez à se moquer de l'ensemble de la CustomerSyncEngine avec ses 3 interfaces, ainsi que toutes les autres dépendances supplémentaires SuperSyncEngine a.

Étant donné que le code que vous cherchez à tester est SuperSyncEngine qui dépend de la CustomerSyncEngine une interface n'est pas la réponse ici. Vous pourrait créer ICustomerSyncEngine mais que l'interface ne devrait pas être créé simplement pour se moquant de cadre. La meilleure solution est de changer CustomerSyncEngine.MethodWithDependencies être virtuel

public virtual void MethodWithDependencies() {
    loggingProvider.Log();
    crmProvider.Crm();
    cacheProvider.Cache();
}

Cela vous permettra de remplacer la méthode avec un moqueur cadre d'ignorer les dépendances qui CustomerSyncEngine qui vient avec.

Si vous suivez cette approche, vous aurez probablement besoin d'un constructeur par défaut exposés sur CustomerSyncEngine pour lui permettre d'être moqué. Il est possible de contourner cela et satisfaire les dépendances avec la valeur null ou certains autres valeurs, mais que serait le travail supplémentaire lorsque l'objectif est de réduire le frottement.

Je sais que cela a été demandé il y a un moment et peut-être n'a pas de valeur pour moi d'ajouter à cela maintenant, mais pour les futurs lecteurs, il ne faut pas se laisser prendre sur la pensée que sont la même chose lors de l'utilisation moq:

var fooDouble = new Mock<IFoo>();

n'est pas la même chose que:

var fooDouble = new Mock<Foo>();

Ma compréhension est que lors de la création d'une Maquette de IFoo, le moq cadre va générer une double classe qui implémente l'IFoo interface, permettant ainsi au constructeur par défaut pour elle-même dans l'généré la mise en œuvre. La maquette de Foo bon, toutefois, de ne pas mettre en œuvre l'interface directement dans le code généré, mais plutôt hérite de la de béton classe Foo et nécessite donc des méthodes qui doivent être écrasé être virtuelles, et si il y a de tout des implémentations concrètes que vous souhaitez réellement utiliser (l'unité sous test, par exemple), alors vous avez besoin "CallBase = true" sur votre maquette. Si c'est ce que vous cherchez à faire avec une classe concrète qui a des arguments du constructeur, vous cherchez peut-être pour @Palkin de réponse afin d'éviter d'exposer un constructeur par défaut.

---

Comme une modification à fait répondre à la question de

comment le code s'occuper de l'avis, La meilleure chose à faire serait de ... Extrait de l'interface?

Les conseils pour en extraire une interface peut ne pas être exactement ce que vous cherchez. Comme il a été mentionné dans d'autres réponses, nous sommes pas sûr de ce que vous êtes réellement en train de tester,.

Si vous essayez de tester fonctionnalité sur le béton Foo mise en œuvre de IFoo puis l'extraction d'une interface et se moquant de IFoo n'est pas vraiment vous aider, car moq va mettre en œuvre l'interface elle-même et fournir seulement les "fonctionnalités" vous dites de lui fournir, dans le programme d'installation méthodes et les propriétés de mise en œuvre. Si c'est ce que vous faites, ET la méthode dans les appels de test d'une autre méthode sur le béton Foo mise en œuvre, ET que la méthode est quelque chose que vous voulez fournir une abstraction, alors je ferais comme @Chris Marisic mentionné et de modifier la méthode que vous avez le désir de l'abstrait au virtual. Avec ce que le virtuel vous peut utiliser un moqueur cadre de l'abstraction, ou faire comme j'ai fait dans le passé et de créer un sous-types de l'objet sous test dans la classe de test.

public class MyFooTests
{
    ... //Tests
    private class SubFoo : Foo
    {
        public override void MethodToAbstract(bool par)
        {
            //do something expected
        }
    }
}

Avec cette méthode, vous allez encore besoin de fournir quelque chose pour le constructeur de Toto, mais ce serait un premier cas d'utilisation se moque sur ces interfaces.

Maintenant, si vous testez Foo et la méthode de test est juste l'appel de méthodes sur IBarIFizzIBuzzet il n'y a pas d'autre abstraction que vous voulez créer, alors vous êtes déjà en place. Se moquer de ceux interfaces, les mettre en place pour rendre ce que vous attendez dans un cas de test, et de fournir Foo avec les objets fantaisie.

L'extrait de l'interface des conseils, c'est vraiment utile lorsque votre objet sous test dépend de Foo, comme mentionné par @Chris Marisic. Cependant, je ne partage pas son sentiment de ne pas vouloir créer des interfaces dans cette situation. Cela dépend de ce que sent de plus pour vous: création d'une interface pour fournir la maquette de capacité, ou de changer le modificateur de fournir le même. Si vous allez changer le modificateur et toujours utiliser moq pour se moquer de béton Foovous aurez besoin d'exposer un constructeur par défaut (assez malodorante pour moi) ou la création de la maquette avec les arguments du constructeur de spécification, comme mentionné dans votre référencé répondre.

Permet de dire que vous avez les éléments suivants:

public class Baz
{
    private Foo foo;

    public Baz(Foo inputFoo)
    {
        this.foo = inputFoo;
    }

    public bool GetFromTheFoo()
    {
        //other stuff here
        var fooStuff = this.foo.GetStuff();
        //logic on the stuff;
        return fooStuff != null;
    }
}

Ci-dessus Baz dépend de Foo. Après l'extraction d'une interface de FooBaz devraient accepter IFoo.

Puis Foo aurait l'air comme il le fait dans votre question et IFoo aurait une définition de la signature de la méthode que vous voulez faire abstraction de Baz.

object GetStuff();

Maintenant, dans votre test, vous devrez utiliser var foo = new Mock<IFoo>(); et donner foo à votre Baz sujet de test. Ne pas oublier de configurer le IFoo.GetStuff() méthode.

foo.Setup(f => f.GetStuff()).Returns(new object());

Parce que vous avez maintenant créé le IFoo l'abstraction n'est pas nécessaire de

contourner le constructeur ici?

parce que le simulacre de IFoo seulement a un constructeur par défaut fournis par moq.

Personnellement, je préfère l'approche de l'interface lorsqu'elle s'applique, car elle élimine IFizzIBuzzet IBar de la chaîne de dépendances sur Baz. Si Baz dépend Foo et Foo dépend IFizz etc.puis Baz dépend aussi de IFizz etc. Après l'extraction de IFooBaz dépend IFoo seulement.

Si vous allez à des tests de votre classe FOo, vous n'avez pas besoin de se moquer. Vous avez seulement besoin de se moquer de ceux des classes qui dépend de la classe que vous essayez de tests.

Quelque chose comme:

Mock<IBar> bar = new Mock<IBar>();
Mock<IBuzz> buzz = new Mock<IBuzz>();
Mock<IFizz> fizz= new Mock<IFizz>();

Foo foo = new Foo(bar.Object, buzz.Object, fizz.Object);

Puis appeler la méthode foo que vous souhaitez tester 😉

Si la méthode foo utilise une méthode à l'intérieur d'un bar/fuzz ou fizz, alors vous devriez utiliser le sintax comme:

buzz.Setup(x => x.DoSomething()).Returns(1);

De cette façon, lorsque votre méthode foo est appelé, il va appeler le DoSomething et toujours sera de retour 1 😉