Son múltiples afirma mal en una prueba de unidad? Incluso si el encadenamiento?

Question

¿Hay algo malo con la comprobación tantas cosas en esta prueba de unidad:?

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 para verificar se devuelve la vista derecha (visita 2) y contiene los datos correctos (visita 4).

¿Me ganar nada dividiendo esto en múltiples pruebas? Soy todo por hacer las cosas bien, pero yo no voy a dividir las cosas si no tiene valor práctico.

Soy bastante nuevo en la unidad de pruebas, así que se gentil.

Answer 1

Como otros han señalado, es mejor seguir con un afirman en cada prueba con el fin de evitar la pérdida de información - si falla el primer afirman, no se sabe si los posteriores fallarían también. Usted tiene que solucionar el problema con menos información -. Que podría (probablemente) será más difícil

Una muy buena referencia es de Roy Osherove arte de la Unidad de Pruebas - si quiere empezar de la Unidad Las pruebas, que podría hacer mucho peor que empezar aquí.

Answer 2

Teniendo en cuenta para futuros lectores que esta cuestión y su duplicado ¿es una mala práctica de tener más de una afirmación en una prueba de unidad? tienen opiniones mayoritarias opuestos, por lo tanto leerlos y decidir por sí mismo.

Mi experiencia es que el cuanto más útil de la prueba no es la afirmación, pero el escenario - es decir, no debe ser una prueba unitaria para un conjunto dado de condiciones iniciales y llamada a un método, con tantas afirmaciones que sean necesarios hacer valer las condiciones finales esperados. Tener una prueba de unidad por la afirmación lleva a duplicar la configuración o soluciones tortuosas para evitar la duplicación (como los terribles contextos rspec profundamente anidados que estoy viendo más y más últimamente). También multiplica pruebas, disminuyendo drásticamente su suite.

Answer 3

Mientras cada afirmación tiene un mensaje único y la identificación de fallos debe ser bueno y va a dejar de lado cualquier problema aserción de ruleta porque no va a ser difícil saber cuál es la prueba falló. Usa el sentido común.

Answer 4

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

  

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

Por ejemplo, está bien que hacer:

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

¿Por qué? - porque estos dos afirma que no se esconde la intención de la prueba. . Si la primera aserción falla, el segundo medio de fallaría también Y de hecho, si quitamos la primera aserción, la segunda aserción falla (con excepción de referencia nula - !!!) de todos modos es cuando el value nulo. Si este no era el caso, entonces no hay que poner estas dos afirma juntos.

Por lo tanto, esto es un error:

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

Como he mencionado anteriormente, si falla el primer afirman, no hay ninguna indicación clara sobre la segunda aserción - tendríamos todavía quiere saber qué pasa con el segundo ( incluso si el primero no ). Así, por esta razón, afirma que estos dos pertenecen a dos pruebas unitarias diferentes.

Conclusión: poner uno o más afirma, Cuando se hace correctamente , se convierte en la cuestión de la preferencia - si queremos ver excepciones afirmación en los resultados de la prueba, o queremos ver algunas otras excepciones así como en casos particulares.

Answer 5

Es mejor quedarse con sólo una aserción en cada prueba para evitar aserción ruleta .

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

Esto asegura que cada caso de prueba a prueba una sola cosa.

Como siempre, hay excepciones a esta regla, pero ya que es nuevo para las pruebas unitarias, recomiendo que se quede con el una afirmación por unidad de prueba regla hasta que haya aprendido cuándo está bien para desviarse.

Answer 6

Sé que esto es una vieja pregunta, pero pensé que me gustaría añadir mi granito de arena.

En general tendría el menor número de afirmaciones como sea posible en cada caso de prueba. Las pruebas a menudo se pueden escribirse para salvar a tener un montón de diferentes afirmaciones.

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 un gran número de diferentes escenarios, no es necesario tener una prueba independiente para cada uno.

Dado el siguiente código, hay muchas afirmaciones diferentes. Cuando no se puede arreglar uno a la vez hasta que las afirmaciones se detienen.

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 recuento de los problemas y hacer valer 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 verdadera situación mundial probablemente me añado alguna huella comandos para escribir el detalle de las pruebas individuales que no llegó a la ventana de salida