c# - visual - ¿Son múltiples los asertos malos en una prueba unitaria? Incluso si encadena?

pruebas unitarias visual studio 2017

Question

¿Hay algún error al verificar tantas cosas en esta prueba unitaria ?:

ActualModel = ActualResult.AssertViewRendered() // check 1
.ForView("Index") // check 2
.WithViewData<List<Page>>(); // check 3
CollectionAssert.AreEqual(Expected, ActualModel); // check 4

Los objetivos principales de esta prueba son verificar que se devuelva la vista correcta (verificación 2) y que contenga los datos correctos (verificar 4).

¿Ganaría algo al dividir esto en múltiples pruebas? Me refiero a hacer las cosas bien, pero no voy a dividir las cosas si no tiene un valor práctico.

Soy bastante nuevo en pruebas unitarias, así que sé gentil.

Answer 1

Como han señalado otros, es mejor seguir con una afirmación en cada prueba para evitar perder información: si la primera afirmación falla, no se sabe si las últimas fallarán también. Tienes que solucionar el problema con menos información, lo que podría ser (probablemente) más difícil.

Una muy buena referencia es el Arte de prueba unitaria de Roy Osherove. Si quieres comenzar bien con las Pruebas unitarias, podrías hacer mucho peor que comenzar aquí.

Answer 2

He encontrado un argumento diferente a esta pregunta (al menos para mí):

El uso de múltiples afirmaciones está bien si están probando lo mismo.

Por ejemplo, está bien hacer:

Assert.IsNotNull(value);
Assert.AreEqual(0, value.Count);

¿Por qué? - porque estas dos afirmaciones no ocultan la intención de la prueba. Si la primera afirmación falla, significa que la segunda falla también. Y de hecho, si eliminamos la primera afirmación, la segunda afirmación falla (con excepción de referencia nula - !!!) de todos modos cuando el value es nulo. Si este no fue el caso, entonces no deberíamos juntar estos dos asertos.

Entonces, esto está mal:

Assert.IsNotNull(value1);
Assert.IsNotNull(value2);

Como mencioné anteriormente, si la primera afirmación falla, no hay una indicación clara sobre la segunda afirmación; aún querríamos saber qué le sucede a la segunda ( incluso si la primera falló ). Entonces, por esta razón, estas dos afirmaciones pertenecen a dos pruebas unitarias diferentes.

Conclusión: poner uno o más asertos, cuando se hace correctamente , se convierte en cuestión de preferencia, ya sea que deseemos ver excepciones de afirmación en los resultados de la prueba, o también queremos ver otras excepciones en casos particulares.

Answer 3

Lo mejor es quedarse con solo una afirmación en cada prueba para evitar la Assertion Roulette .

Si necesita configurar el mismo escenario para probar varias condiciones basadas en premisas idénticas, es mejor extraer el código de configuración a un método de ayuda compartida, y luego escribir varias pruebas que llaman a este método de ayuda.

Esto asegura que cada caso de prueba prueba solo una cosa.

Como siempre, hay excepciones a esta regla, pero como usted es nuevo en las pruebas unitarias, le recomendaría que se apegue a la regla de prueba de una afirmación por unidad hasta que haya aprendido cuándo puede desviarse.

Answer 4

Observando para los lectores futuros que esta pregunta y su duplicado ¿Es una mala práctica tener más de una afirmación en una prueba unitaria? tener opiniones de mayoría opuestas, así que léalas y decida por usted mismo.

Mi experiencia es que el quantum de prueba más útil no es la aserción, sino el escenario, es decir, debe haber una prueba unitaria para un conjunto determinado de condiciones iniciales y una llamada a método, con tantas aserciones como sean necesarias para afirmar el condiciones finales esperadas. Tener una prueba unitaria por afirmación conduce a una configuración duplicada o soluciones temporales tortuosas para evitar la duplicación (como los horribles contextos rspec profundamente anidados que veo cada vez más últimamente). También multiplica las pruebas, ralentizando drásticamente su suite.

Answer 5

Sé que esta es una vieja pregunta, pero pensé que agregaría mi parte.

En general, tendría las menos afirmaciones posibles en cada caso de prueba. Las pruebas se pueden escribir a menudo para ahorrar muchas aserciones diferentes.

Supongamos que tengo pruebas unitarias para un método que crea un saludo (por ejemplo, el Sr. Smith) a partir de los componentes de un nombre. Quiero comprobar esto con una gran cantidad de escenarios diferentes, no es necesario tener una prueba separada para cada uno.

Dado el siguiente código, hay muchas aserciones diferentes. Cuando fallan, puede solucionarlos de uno en uno hasta que se detengan las afirmaciones.

Assert.AreEqual("Mr Smith", GetSalutation("Mr", "J", "Smith"));
Assert.AreEqual("Mr Smith", GetSalutation("Mr", "John", "Smith"));
Assert.AreEqual("Sir/Madam", GetSalutation("", "John", "Smith"));
Assert.AreEqual("Sir/Madam", GetSalutation("", "J", "Smith"));

Una alternativa a esto es mantener un conteo de los problemas y afirmar esto al final.

int errorCount = 0;
string result;
result = GetSalutation("Mr", "J", "Smith");
if (result == "Mr Smith")
errorCount++;
result = GetSalutation("Mr", "John", "Smith");
if (result == "Mr Smith")
errorCount++;
Assert.AreEqual(0, errorCount);

En una situación del mundo real, probablemente agregaría algunos comandos Trace para escribir el detalle de las pruebas individuales que fallaron en la ventana de salida.

Answer 6

Siempre que cada afirmación tenga un mensaje único e identificativo de falla, deberías ser bueno e ignorarás cualquier problema de la Assertion Roulette porque no será difícil saber qué prueba falló. Usa el sentido común.