c# - the - Moq, uso estricto vs uso libre

use the function form of use strict

Question

En el pasado, solo he usado Rhino Mocks, con el típico simulacro estricto. Ahora estoy trabajando con Moq en un proyecto y me pregunto sobre el uso correcto.

Supongamos que tengo un objeto Foo con método Bar que llama a un método Bizz en el objeto Buzz.

En mi prueba, quiero verificar que se llame a Bizz, por lo tanto, creo que hay dos opciones posibles:

Con un simulacro estricto

var mockBuzz= new Mock<IBuzz>(MockBehavior.Strict);
mockBuzz.Setup(x => x.Bizz()); //test will fail if Bizz method not called
foo.Buzz = mockBuzz
foo.Bar();
mockBuzz.VerifyAll();

Con una simulación suelta

var mockBuzz= new Mock<IBuzz>();
foo.Buzz = mockBuzz
foo.Bar();
mockBuzz.Verify(x => x.Bizz()) //test will fail if Bizz method not called

¿Hay una forma estándar o normal de hacer esto?

Answer 1

Personalmente, soy nuevo en la burla y Moq siente que comenzar con el modo Estricto ayuda a comprender mejor las entrañas y lo que está sucediendo. "Suelto" a veces oculta detalles y pasa una prueba que un principiante moq puede no ver. Una vez que tenga sus habilidades de burla - Loose probablemente sería mucho más productivo - como en este caso guardar una línea con la "Configuración" y simplemente usar "Verificar" en su lugar.

Answer 2

Solía ​​usar simulaciones estrictas cuando comencé a usar simulaciones en pruebas unitarias. Esto no duró mucho tiempo. En realidad, hay 2 razones por las que dejé de hacer esto:

1. Las pruebas se vuelven frágiles: con los simulacros estrictos, usted está afirmando más de una cosa, que los métodos de configuración se llaman, Y que los otros métodos no son llamados. Cuando refactoriza el código, la prueba a menudo falla, incluso si lo que está intentando probar sigue siendo cierto.
2. Las pruebas son más difíciles de leer: debe tener una configuración para cada método invocado en el simulacro, incluso si no está realmente relacionado con lo que desea probar. Cuando alguien lee esta prueba, es difícil para ellos decir qué es importante para la prueba y cuál es solo un efecto secundario de la implementación.

Debido a esto, recomendaría encarecidamente usar simulaciones sueltas en las pruebas de su unidad.

Answer 3

Tengo experiencia en el desarrollo de C ++ / non.NET y he estado más en .NET recientemente, así que tenía ciertas expectativas cuando estaba usando Moq por primera vez. Estaba tratando de entender que WTF estaba pasando con mi prueba y por qué el código que estaba probando arrojaba una excepción aleatoria en lugar de la biblioteca Mock que me indicaba qué función intentaba llamar el código. Así que descubrí que necesitaba activar el comportamiento Estricto, lo cual era desconcertante, y luego me encontré con esta pregunta que, como vi, todavía no tenía una respuesta específica.

El modo Loose , y el hecho de que es el predeterminado es una locura . ¿Qué diablos es el objetivo de una biblioteca Mock que hace algo totalmente impredecible que no has enumerado explícitamente que debería hacer?

Estoy completamente en desacuerdo con los puntos enumerados en las otras respuestas en apoyo del modo Loose. No hay una buena razón para usarlo y nunca lo quisiera, nunca. Al escribir una prueba de unidad, quiero estar seguro de lo que está sucediendo: si sé que una función necesita devolver un valor nulo, lo haré regresar. Quiero que mis pruebas sean frágiles (en la forma en que importan) para que pueda corregirlas y agregar al paquete de códigos de prueba las líneas de configuración que son la información explícita que me describe exactamente lo que hará mi software.

La pregunta es: ¿hay una forma estándar y normal de hacer esto?

Sí, desde el punto de vista de la programación en general, es decir, otros lenguajes y fuera del mundo .NET, debe usar Strict siempre. Dios sabe por qué no es el valor predeterminado en Moq.

Answer 4

Tengo una convención simple:

1. Utilice simulaciones estrictas cuando el sistema sometido a prueba (SUT) delegue la llamada a la capa burlada subyacente sin modificar o aplicar realmente ninguna lógica comercial a los argumentos pasados ​​a sí mismo.

2. Use burlas sueltas cuando el SUT aplica lógica comercial a los argumentos pasados ​​a sí mismo y transmite algunos valores derivados / modificados a la capa burlada.

Por ejemplo: digamos que tenemos el proveedor de base de datos StudentDAL que tiene dos métodos:

La interfaz de acceso a datos se ve a continuación:

public Student GetStudentById(int id);
public IList<Student> GetStudents(int ageFilter, int classId);

La implementación que consume este DAL se ve a continuación:

public Student FindStudent(int id)
{
//StudentDAL dependency injected
return StudentDAL.GetStudentById(id);
//Use strict mock to test this
}
public IList<Student> GetStudentsForClass(StudentListRequest studentListRequest)
{
//StudentDAL dependency injected
//age filter is derived from the request and then passed on to the underlying layer
int ageFilter = DateTime.Now.Year - studentListRequest.DateOfBirthFilter.Year;
return StudentDAL.GetStudents(ageFilter , studentListRequest.ClassId)
//Use loose mock and use verify api of MOQ to make sure that the age filter is correctly passed on.
}