Autofixture: Obtenez l'instance de l'interface interne créée par AutoMoqData.

essayer

Mock.Get(sut).Setup(x => x.Method).Result(something);

Vous obtiendrez l'instance d'objet n'a pas été créée par Moq. accédant à sut.

Cela fonctionnera réellement si l'interface est dans une propriété publique.
Mock.Get(sut.InnerInterface).Setup(x => x.Method).Result(quelque chose);

Mais que se passe-t-il si l'interface est moquée et injectée par le constructeur, enregistrée dans le conteneur IoC mais non accessible en sut avec une propriété publique ?

Dans ce cas, vous devrez geler la simulation pour vous assurer que l'instance que vous générez sera également injectée dans le sut :

[Theory, AutoMoqData]
public void Dummy(
    IFixture fixture, 
    [Frozen]Mock<YourInnerInterface> innerInterfaceMock,
    ComplexClassWithInnerInterface sut)
{
    innerInterfaceMock.Setup(x => x.Method).Result(something);
    sut.DoSomething();
    Assert.Equal(String.Empty, String.Empty);
}

Veillez à toujours créer les mocks congelés avant le sut afin qu'ils existent déjà lors de la création du sut et donc qu'ils soient correctement injectés.

Voir le blog de

Salut,
Je faisais déjà ça. Mais pour 30 interfaces, c'est assez moche de les avoir dans les paramètres de méthode.
Votre code m'a rappelé qu'AutoMoqData ne gèle pas toutes les interfaces simulées. Il semble donc impossible d'obtenir des maquettes créées automatiquement à partir du conteneur de l'appareil. Ils ne sont pas injectés par défaut, donc si le luminaire avait une méthode semblable à GetInstance, il ne renverra rien pour les mocks créés automatiquement. C'est pourquoi j'obtiens des doublons si je fige le simulacre avec l'instance de luminaire. La seule façon dont je vois que cela fonctionnerait serait si le sut pouvait être mis à jour avec les maquettes gelées ultérieures, mais ce serait moche. Le moyen le plus simple consiste à utiliser AutoMoqData pour créer les maquettes IFixture, geler et configurer dans la méthode de test, puis créer sut. Avec cette configuration, je peux créer une méthode d'assistance réutilisable pour geler et configurer des simulations.

Merci

Merci @xlecoustillier pour cette excellente réponse. Fondamentalement, je suggérerais de faire la même chose car je suis constamment ce modèle dans mes tests.

Mais pour 30 interfaces, c'est assez moche de les avoir dans les paramètres de méthode.

Eh bien, cet argument a l'air un peu bizarre. Probablement, il est quelque chose de mal avec la conception de code testé si vous devez configurer 30 dépendances pour faire un scénario 😟 Je suis 99% @ploeh vous suggère de revoir le code avant de poursuivre, selon ses conseils , il est recommandé d'avoir max 3-4 dépendances 😅

Il semble donc impossible d'obtenir des maquettes créées automatiquement à partir du conteneur de l'appareil. Ils ne sont pas injectés par défaut, donc si le luminaire avait une méthode semblable à GetInstance, il ne renverra rien pour les mocks créés automatiquement.

Je ne suis pas sûr à 100% d'avoir bien compris tout le message, mais d'après ce que j'ai compris, vous avez raison. Par défaut, tous les objets générés sont transitoires et fixture ne les préserve pas. Si vous souhaitez faire l'objet particulier un singleton, vous devez utiliser le fixture.Freeze<>() API ou [Frozen] attribut ou toute autre API appropriée.
Le comportement par défaut existant a été conçu pour couvrir les scénarios courants et dans la plupart des cas, vous ne voulez pas avoir le même objet par type.

Si vous recherchez toujours de l'aide de notre part, veuillez fournir des exigences plus précises que vous avez. Mieux, partagez suffisamment de code pour démontrer les limites actuelles et l'objectif que vous souhaitez atteindre - cela vous aidera à mieux synchroniser 😉

Merci.

Oui, je dirais que 30 dépendances sont de trop.

En ce qui concerne l'accès aux dépendances injectées, l'utilisation de l'attribut [Frozen] , comme le suggère @xlecoustillier , est une option, et en fait la raison pour laquelle cet attribut existe à l'origine.

L'utilisation de Mock.Get(sut.Dep1) est également une option que j'utilise souvent.

Mais que se passe-t-il si l'interface est [...] injectée par le constructeur [...] mais n'est pas accessible en sut avec une propriété publique ?

Pourquoi ne pas l'exposer en tant que propriété, alors ? Ce que vous composez, vous pouvez aussi l'exposer. . Il ne casse pas l'encapsulation pour l'exposer.

J'ai envie d'ajouter @ploeh en précisant que la meilleure approche est d'exposer les dépendances en tant que propriétés de classe sans enrichir votre abstraction ce qui ne serait rien de plus qu'une fuite de votre implémentation !

@ malylemire1 Fermeture de ceci car il semble qu'aucune aide supplémentaire ne soit requise. S'il vous plaît laissez-nous savoir s'il y a autre chose que nous pouvons vous aider

Merci pour une fois de plus d'avoir soulevé la question! ??