Autofixture: Obtenga una instancia de la interfaz interna creada por AutoMoqData.

tratar

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

Obtendrá la instancia de Objeto no creada por Moq. accediendo a sut.

Esto realmente funcionará si la interfaz está en una propiedad pública.
Mock.Get (sut.InnerInterface) .Setup (x => x.Method) .Result (algo);

Pero, ¿qué pasa si se simula la interfaz y se inyecta el constructor, registrado en el contenedor de IoC pero no accesible en sut con una propiedad pública?

En este caso, tendrá que congelar el simulacro para asegurarse de que la instancia que genere también se inyecte en el 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);
}

Tenga cuidado de crear siempre los simulacros congelados antes del sut para que ya existan cuando se cree el sut y, por lo tanto, se inyecten correctamente.

Consulte el blog de

Hola,
Ya estaba haciendo eso. Pero para 30 interfaces es bastante feo tenerlas en los parámetros del método.
Su código me recordó que AutoMoqData no congela todas las interfaces simuladas. Por lo tanto, parece imposible obtener simulaciones creadas automáticamente desde el contenedor del dispositivo. No se inyectan de forma predeterminada, por lo que si el accesorio tenía un método similar a GetInstance, no devolverá nada para los simulacros creados automáticamente. Es por eso que obtengo duplicados si congelo el simulacro con la instancia del accesorio. La única forma en que veo que funcionaría es si el sut pudiera actualizarse con los simulacros congelados posteriores, pero eso sería feo. La forma más fácil es utilizar AutoMoqData para crear el IFixture, congelar y configurar simulacros en el método de prueba, luego crear sut. Con esta configuración puedo crear un método auxiliar reutilizable para congelar y configurar simulacros.

Gracias

Gracias @xlecoustillier por la gran respuesta. Básicamente, sugeriría hacer lo mismo, ya que sigo constantemente este patrón en mis pruebas.

Pero para 30 interfaces es bastante feo tenerlas en los parámetros del método.

Bueno, este argumento parece un poco extraño. Probablemente, hay algo mal con el diseño del código probado si necesita configurar 30 dependencias para crear un escenario 😟 Soy 99% @ploeh le sugiero que revise el código primero antes de continuar, según su consejo, se recomienda tener max 3-4 dependencias 😅

Por lo tanto, parece imposible obtener simulaciones creadas automáticamente desde el contenedor del dispositivo. No se inyectan de forma predeterminada, por lo que si el accesorio tenía un método similar a GetInstance, no devolverá nada para los simulacros creados automáticamente.

No estoy 100% seguro de haber entendido todo el mensaje con claridad, pero por lo que tengo, tienes razón. Por defecto, todos los objetos generados son transitorios y fixture no los conserva. Si desea convertir el objeto en particular en un singleton, debe utilizar el atributo fixture.Freeze<>() API o [Frozen] o cualquier otra API adecuada.
El comportamiento predeterminado existente se diseñó para cubrir los escenarios comunes y, en la mayoría de los casos, _no desea_ tener el mismo objeto por tipo.

Si todavía está buscando la ayuda de nuestra parte, proporcione un requisito más exacto que tenga. Mejor, comparta suficiente código para demostrar las limitaciones actuales y el objetivo que le gustaría lograr, lo que ayudará a sincronizar mejor 😉

Gracias.

Sí, sugeriría que 30 dependencias son demasiadas.

Con respecto a obtener las dependencias inyectadas, usar el atributo [Frozen] , como sugiere @xlecoustillier , es una opción y, de hecho, la razón por la que ese atributo existe originalmente.

Usar Mock.Get(sut.Dep1) también es una opción que uso a menudo.

Pero, ¿qué pasa si la interfaz es [...] inyectada por el constructor pero no [...] accesible en sut con una propiedad pública?

Entonces, ¿por qué no exponerlo como una propiedad? Lo que compones, también lo puedes exponer. . No rompe la encapsulación para exponerlo.

Tengo ganas de agregar @ploeh especificando que el mejor enfoque es exponer las dependencias como propiedades de clase sin enriquecer su abstracción, lo que no sería más que filtrar su implementación.

@ malylemire1 Cerrando esto ya que parece que no se requiere más ayuda. Háganos saber si hay algo más en lo que podamos ayudarlo 😉

¡Gracias por una vez más por plantear la pregunta! 👍