¿Cuánto se debe Cada Prueba Prueba de la unidad?

Question

¿Cuánto se debe examinar cada uno de mis pruebas de unidad? Por ejemplo tengo esta prueba

[TestMethod]
public void IndexReturnsAView()
{
    IActivityRepository repository = GetPopulatedRepository();
    ActivityController activityController = GetActivityController(repository);
    ActionResult result = activityController.Index();
    Assert.IsInstanceOfType(result, typeof(ViewResult));
}

y

[TestMethod]
public void IndexReturnsAViewWithAListOfActivitiesInModelData()
{
    IActivityRepository repository = GetPopulatedRepository();
    ActivityController activityController = GetActivityController(repository);
    ViewResult result = activityController.Index() as ViewResult;
    Assert.IsInstanceOfType(result.ViewData.Model, typeof(List<Activity>));
}

Es evidente que si la primera prueba falla, por lo que será la segunda prueba para estos dos debe ser combinado en una sola prueba con dos afirma? Mi sensación es que el más detallado de las pruebas y los menos cada prueba comprueba el más rápido será el de encontrar las causas de los fracasos. Sin embargo hay una actividad general a tener un gran número de pequeñas pruebas que podría costar tiempo en la gestión de todas las pruebas.

Answer 1

Me gustaría recomendar romper hacia abajo tanto como sea posible.

Hay muchas razones para esto, en mi humilde opinión los más importantes son:

• Cuando una de las pruebas falla, usted quiere ser capaz de aislar exactamente lo que salió mal lo más rápida y segura posible. Teniendo cada método de ensayo única prueba una sola cosa es la mejor manera de lograr esto.

• Cada prueba tiene que comenzar con una pizarra limpia. Si crea el repositorio una vez y luego lo utiliza en 2 o más pruebas, entonces usted tiene una dependencia implícita del orden de dichas pruebas. Decir Prueba1 añade un elemento al repositorio, pero se olvida de eliminarlo. El comportamiento de test2 ahora será diferente, y posiblemente hacer que el error de la prueba. La única excepción a esto es los datos inmutables.

En cuanto a sus preocupaciones de velocidad, yo no me preocuparía por eso. Para el código de crujir puro como este, .NET es muy rápido, y nunca serás capaz de notar la diferencia. Tan pronto como salga de código-crujido y en cosas como bases de datos, entonces se sentirá los problemas de rendimiento, pero tan pronto como lo hace que se ejecuta en todos los temas "borrón y cuenta nueva", como se describió anteriormente, por lo que es posible que sólo tienen que vivir con ella (o hacer la mayor cantidad de sus datos inmutables como sea posible).

Buena suerte con sus pruebas.

Answer 2

El más fino, mejor. Cuando una aserción falla en un caso de prueba, el caso de prueba no se ejecuta más allá. Las últimas partes del caso potencialmente podrían descubrir otros errores.

Si hay código compartido entre los casos de prueba, utilice las funciones de instalación / desmontaje de cuidar de que sin repetir demasiado. costo de tiempo es a menudo insignificante. Si el programa de instalación / desmontaje lleva demasiado tiempo, probablemente no estás haciendo las pruebas unitarias, pero algunas pruebas automatizado nivel superior. Las pruebas unitarias idealmente no deben tener sistema de archivos, red, etc. dependencias de base de datos.

Answer 3

Creo que la respuesta "estándar" es que debe llegar al punto de que si hay un error en el código, se debe romper una prueba, pero no ocultar cualquier otros fallos (no dejar las otras pruebas de funcionamiento) cuando éste falla. Cada prueba verifica una cosa y dos pruebas no prueba la misma cosa. Eso es un ideal, no siempre acheivable. Consultenos.

Una vez dicho esto, es realmente un arte. Me gustaría dejar a un lado los problemas de rendimiento en un principio, y se centran más en el mantenimiento. Allí usted tiene dos y medio a tres líneas de duplicación. Si los cambios de diseño, que hará que difícil de mantener. La duplicación de por sí puede ser resuelto por un método de configurar una un presentadas en la clase, en este caso, pero lo más importante es preocuparse por el mantenimiento.

Las pruebas deben ser lo suficientemente pequeño para ser fácil de mantener y fácil de entender, y es algo que hace que sea razonable para los demás (o después de que haya pasado el tiempo) para entender lo que el código está haciendo y ser capaz de mantener las pruebas.

Answer 4

Una unidad de prueba debe probar exactamente eso lo que se describe en su diseño técnico en perspectiva del diseño funcional.

Answer 5

El enfoque de la cantidad de pruebas a prueba es definitivamente algo que tiene que decidir por adelantado y se adhieren a ella. No creo que todo el mundo debe seguir el mismo enfoque de manera uniforme, ya que diferentes equipos y / o proyectos tienen diferentes prioridades hacia la codificación, el rendimiento, la solución de problemas, infraestructura de pruebas, etc, pero siempre ser coherente ayudarán a:

1. identificar más rápidamente los problemas ya se sabe de antemano qué tan profundo para excavar;
2. pasan menos tiempo en la construcción sus pruebas;
3. emplear el mismo conjunto de clases de ayuda de prueba mientras la implementación de pruebas.
4. ejecutar pruebas lo suficientemente rápido:. No demasiado rápido y no demasiado lento
5. organización de pruebas (suites, paquetes, etc.)

Si decide que el rendimiento es más importante entonces aplicar pruebas más gruesas con más validaciones / asserttions. Si decide que la resolución de problemas es una suma continuación, aislar sus pruebas tanto como sea necesario. No puedo ver por qué están viciadas pruebas gruesas y bien estructurados. Estas pruebas podrían obtener el mismo trabajo hecho como una mayor cantidad de pruebas más delgadas y tan bien.

Por supuesto, todas las pruebas todavía tiene que centrarse en particular, la función / característica, pero esto no es realmente el tema de este hilo.