unit testing - tipos - ¿Cuánto debería cada prueba de prueba de unidad?

pruebas unitarias php

Question

¿Cuánto debería examinar cada una de las pruebas de mi 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 también

[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>));
}

Obviamente, si la primera prueba falla, también lo hará la segunda prueba, ¿deberían combinarse estas dos en una prueba con dos afirmaciones? Mi sensación es que cuanto más granulares sean las pruebas y menos verifique cada prueba, más rápido será encontrar las causas de las fallas. Sin embargo, existe una gran cantidad de pruebas muy pequeñas que pueden costar tiempo en la ejecución de todas las pruebas.

Answer 1

Creo que la respuesta "estándar" es que debe llegar al punto de que si hay un error en el código, debe romper una prueba, pero no ocultar ningún otro error (no detener el funcionamiento de las otras pruebas) cuando este falla. . Cada prueba prueba una cosa y dos pruebas no prueban lo mismo. Ese es un ideal, no siempre alcanzable. Llámalo orientación.

Dicho eso, es realmente un arte. Dejaría de lado los problemas de rendimiento inicialmente y me enfocaría más en la facilidad de mantenimiento. Ahí tienes dos y medio a tres líneas de duplicación. Si el diseño cambia, será difícil mantenerlo. La duplicación per se puede resolverse mediante un método de configuración y un archivo en la clase en este caso, pero lo principal de lo que preocuparse es la facilidad de mantenimiento.

Las pruebas deben ser lo suficientemente pequeñas como para ser mantenibles, fáciles de entender, y algo que haga razonable que otros (o usted después de que haya pasado el tiempo) entiendan lo que el código está haciendo y sean capaces de mantener las pruebas.

Answer 2

Cuanto más fino, mejor. Cuando una afirmación falla en un caso de prueba, el caso de prueba no se ejecuta más. Las últimas partes del caso podrían revelar otros errores.

Si hay código compartido entre los casos de prueba, use las funciones de configuración / desmontaje para ocuparse de eso sin repetirse demasiado. El costo de tiempo es a menudo insignificante. Si la instalación / desmontaje toma demasiado tiempo, probablemente no esté realizando pruebas unitarias sino algunas pruebas automatizadas de nivel superior. Las pruebas unitarias idealmente no deberían tener dependencias de sistemas de archivos, redes, bases de datos, etc.

Answer 3

Recomiendo desglosarlos tanto como sea posible.

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

• Cuando una de sus pruebas falla, desea poder aislar exactamente lo que salió mal de la manera más rápida y segura posible. Tener cada método de prueba solo prueba una sola cosa es la mejor manera de lograr esto.

• Cada prueba debe comenzar con un borrón y cuenta nueva. Si crea el repositorio una vez y luego lo usa en 2 o más pruebas, entonces tiene una dependencia implícita en el orden de esas pruebas. Say Test1 agrega un elemento al repositorio pero se olvida de eliminarlo. El comportamiento de Test2 ahora será diferente y posiblemente haga que su prueba falle. La única excepción a esto son los datos inmutables.

En cuanto a sus preocupaciones sobre la velocidad, no me preocuparía. Para el cifrado de código puro como este, .NET es muy rápido, y nunca podrás notar la diferencia. Tan pronto como se salga del control de código y en cosas como bases de datos, entonces sentirá los problemas de rendimiento, pero tan pronto como lo haga se encontrará con todos los problemas de "borrón y cuenta nueva" descritos anteriormente, por lo que puede tiene que vivir con eso (o hacer que la mayor cantidad posible de sus datos sea inmutable).

La mejor de las suertes con tu prueba.

Answer 4

Una prueba unitaria debería probar exactamente lo que se describe en su diseño técnico en perspectiva del diseño funcional.

Answer 5

El enfoque sobre cuánto prueba una prueba definitivamente es algo que debes decidir por adelantado y aferrarte a ella. No creo que todos deban seguir el mismo enfoque de manera uniforme, ya que los diferentes equipos y / o proyectos tienen diferentes prioridades para la codificación, el rendimiento, la resolución de problemas, la infraestructura de pruebas, etc. Pero ser consecuente siempre ayudará:

1. Identifique problemas más rápidamente ya que sabe de antemano qué tan profundo excavar;
2. dedique menos tiempo a la construcción de sus pruebas;
3. emplear el mismo conjunto de clases de ayuda de prueba durante la implementación de pruebas.
4. ejecutar pruebas lo suficientemente rápido: no demasiado rápido y no demasiado lento.
5. organizar pruebas (suites, paquetes, etc.)

Si decide que el rendimiento es más importante, implemente pruebas más gruesas con más validaciones / afirmaciones. Si decide que la solución de problemas es primordial, aísle sus pruebas tanto como sea necesario. No puedo ver por qué las pruebas gruesas y bien estructuradas son defectuosas. Dichas pruebas realizarían el mismo trabajo que una mayor cantidad de pruebas más delgadas y también.

Por supuesto, cada prueba todavía necesita enfocarse en una función / función particular, pero este no es realmente el tema de este hilo.