TDD Organizar Actuar Patrón de Assert cuando se usa Mocks para verificar llamadas de dependencia

Question

Estoy usando Moq para probar el comportamiento de algunos métodos nulos. Usando MockBehaviour.Strict cada llamada al simulacro debe especificarse durante el paso Arrange. Esto está dando como resultado que muchas pruebas no tengan ningún paso Assert (o Verificar). La condición de pase es simplemente que la prueba se ejecutó sin lanzar una excepción. ¿Me estoy perdiendo de algo? ¿El patrón Arrange, Act, Assert no es adecuado cuando se usan simulaciones estrictas? ¿Hay una forma más semántica de diseñar estas pruebas?

Un trivial formada por ejemplo ...

[TestClass] 
public void DeleteUser_ShouldCallDeleteOnRepository() 
{ 
    // Arrange 
    var userRepository = new Mock<IUserRepository>(MockBehavior.Strict); 

    int userId = 9; 
    userRepository.Setup(x => x.Delete(userId)); 

    var controller = new UserController(userRepository.Object); 

    // Act 
    controller.DeleteUser(userId); 

    // Assert 
    // ...? 
} 

Answer 1

Su maqueta está tomando el lugar de un colaborador. Está idealmente hacer una de dos cosas:

• Proporcionar información o datos
• Hacer un trabajo

Cuando la maqueta está proporcionando información o datos, es suficiente con que este debe ser un trozo . Puede configurar el valor de retorno de la simulación para la información requerida. Esto debería ser parte de Organizar.

Cuando el simulacro está haciendo un trabajo, la delegación puede ser verificado. Es por eso que tiene Assert.

Lo que está haciendo con la interacción estricta es asegurarse de que se espera cada interacción, básicamente diciendo: "Esto es lo que espero que pase, y si sucede algo más, está mal". Este es un tipo diferente de prueba para Actuar, Organizar, Afirmar, que dice: "En este contexto, cuando hago estas cosas, entonces debería obtener este resultado".

Con un simulacro "agradable", solo tiene que preocuparse por las interacciones que le interesan. Entonces, por ejemplo, si soy un controlador y estoy buscando información en un repositorio, validarlo con un validador, a continuación, guardar el resultado en otro repositorio, que podría tener varias pruebas:

• uno para comprobar que estoy en contra validar la información correcta
• uno para comprobar cómo estoy respondiendo a la validación incorrecta
• y uno para verificar que guarde el artículo.

Con la maqueta estricta, que tiene que hacer todos los las expectativas, aunque lo único que le interesa es la opción "Guardar". Al usar un buen simulacro, podemos dividir los diferentes aspectos del comportamiento y solo enfocarnos en uno de ellos en cada prueba.

Como un beneficio adicional, agradables burla le permiten hacer:

• dado un contexto
• Cuando ocurre este evento
• A continuación, este resultado debe ocurrir

Mientras se burla estrictas hacen usted lo hace:

• Given un contexto
• esperar algunas cosas suceda
• Cuando realizo un evento
• después volver atrás y leer lo que el resultado debería haber sido en realidad.

El primero de estos se considera generalmente más legible.