¿Cuál es el valor de verificar en las pruebas unitarias fallidas?

13

Si bien hay formas de evitar que se ejecuten las pruebas unitarias, ¿cuál es el valor de verificar las pruebas unitarias fallidas?

Usaré un ejemplo simple: Sensibilidad al caso. El código actual distingue entre mayúsculas y minúsculas. Una entrada válida en el método es "Cat" y devolvería una enumeración de Animal.Cat. Sin embargo, la funcionalidad deseada del método no debe distinguir entre mayúsculas y minúsculas. Entonces, si el método descrito se pasara "cat", posiblemente podría devolver algo como Animal.Null en lugar de Animal.Cat y la prueba de la unidad fallaría. Aunque un simple cambio de código haría que esto funcionara, un problema más complejo puede tardar semanas en solucionarse, pero identificar el error con una prueba de unidad podría ser una tarea menos compleja.

La aplicación que se está analizando actualmente tiene 4 años de código que "funciona". Sin embargo, las discusiones recientes sobre las pruebas unitarias han encontrado fallas en el código. Algunos solo necesitan documentación de implementación explícita (por ejemplo, sin distinción de mayúsculas y minúsculas), o código que no ejecute el error en función de cómo se llama actualmente. Pero se pueden crear pruebas unitarias ejecutando escenarios específicos que harán que el error se vea y sean entradas válidas.

  

¿Cuál es el valor de verificar en las pruebas unitarias que ejercen el error hasta que alguien pueda arreglar el código?

¿Debería marcarse esta prueba de unidad con ignorar, prioridad, categoría, etc., para determinar si una compilación fue exitosa en base a las pruebas ejecutadas? Finalmente, se debe crear la prueba de la unidad para ejecutar el código una vez que alguien lo arregla.

Por un lado, muestra que los errores identificados no se han solucionado. Por otro lado, podría haber cientos de pruebas de unidades fallidas que aparecen en los registros y que eliminan las que deberían fallar en comparación con las fallas debidas a una verificación de código sería difícil de encontrar.

    
pregunta Jim G. 15.03.2011 - 16:01

8 respuestas

17

A no me gustan las pruebas de unidad rotas porque producen un ruido innecesario. Después de cada prueba de unidad tendría que revisar todos los problemas fallidos (rojo). Es rojo porque hay un problema nuevo o porque hay un antiguo abierto para hacer / solucionar. Esto no está bien si hay más de 20 pruebas de unidad.

En su lugar yo uso

  • Atributo [Ignore("Reason")] que hace que el resultado sea amarillo o
  • throw new NotImplementedException() que hace que el resultado sea gris

Nota: Estoy usando NUnit para .net. No estoy seguro de si la característica "gris" está allí en otros marcos de prueba de unidad.

Así que me gusta el siguiente significado de resultados de pruebas unitarias.

  • verde: todo terminado
  • gris: nuevas funciones planificadas que deben realizarse pero con baja prioridad
  • amarillo: errores aún no corregidos. Debe ser arreglado pronto
  • rojo: bugs nuevos. Debe ser arreglado inmediatamente

Se puede registrar todo excepto "rojo".

Para responder a la pregunta: hay más daño que valor para registrar "testes fallidos en rojo", pero el control en "pruebas ignoradas en amarillo" o "pruebas no detectadas en gris" puede ser útil como una lista de tareas pendientes. .

    
respondido por el k3b 16.03.2011 - 07:17
8

No pretenderé que este es un estándar de la industria, pero verifico las pruebas rotas como una forma de recordarme a mí oa mis otros miembros del proyecto que todavía hay un problema con el código o la prueba de la unidad en sí.

Supongo que una cosa a considerar es si sus políticas de desarrollo permiten pruebas fallidas sin penalización. Tengo un amigo que trabaja en una tienda que realiza desarrollo guiado por pruebas, por lo que siempre comienzan con pruebas fallidas ...

    
respondido por el Tieson T. 15.03.2011 - 16:16
6

Las pruebas unitarias que fallan le dan al equipo de desarrollo visibilidad de lo que se debe hacer para cumplir con las especificaciones acordadas.

En resumen, las pruebas unitarias que fallan le dan al equipo una lista de "TODO".

Por esta razón, las pruebas unitarias que fallan son lejos mejor que ninguna prueba unitaria. *
La ausencia de pruebas unitarias deja al equipo de desarrollo en la oscuridad; las especificaciones deben confirmarse repetidamente manualmente .

[* Siempre que las pruebas unitarias realmente prueben algo útil.]

    
respondido por el Jim G. 15.03.2011 - 21:42
5

El propósito de las pruebas unitarias es afirmar el comportamiento esperado de un sistema, no documentar defectos. Si utilizamos pruebas unitarias para documentar defectos, entonces se reduce su utilidad para afirmar el comportamiento esperado. La respuesta a la pregunta "¿Por qué falló esta prueba?" no es un simple "Oh, algo está roto que no esperaba que me rompieran". Se ha vuelto desconocido si la falla de la prueba es esperada o inesperada.

Aquí hay un párrafo desde el principio del capítulo 13 de Cómo trabajar con eficacia con el código heredado :

  

Las pruebas unitarias automatizadas son una herramienta muy importante, pero no para la búsqueda de errores, al menos no directamente. En general, las pruebas automatizadas deben especificar un objetivo que nos gustaría cumplir o intentar preservar el comportamiento que ya existe. En el flujo natural del desarrollo, las pruebas que especifican se convierten en pruebas que conservan . Encontrará errores, pero generalmente no es la primera vez que se ejecuta una prueba. Encontrará errores en las ejecuciones posteriores cuando cambie el comportamiento que no esperaba.

    
respondido por el Matthew Rodatus 30.03.2011 - 17:40
3

Pero los rotos que identifican errores en un nuevo proyecto, nombrados como tales. De esa manera, puedes ver que DEBEN romperse ... A medida que se están arreglando, se volverán verdes y se moverán a la suite de prueba normal.

NOTA: ese proyecto tendría que configurarse para que no se compile en el servidor de compilación, si su servidor de compilación evita los registros que rompen la compilación (suponiendo que defina una compilación rota como una en la que no pasan todas las pruebas)

    
respondido por el CaffGeek 15.03.2011 - 16:10
2

Las pruebas unitarias deben probar los casos de error además de los casos de éxito de una función. Una función debe rechazar explícitamente una entrada incorrecta o debe tener documentación para explicar qué entrada se considera válida.

Si tienes una función que no está haciendo ninguna de esas cosas, es un error y deberías tener una forma de registrar que existe. Crear una prueba de unidad que demuestre este problema es una forma de hacerlo. Archivar un ticket de error es otra opción.

El punto de prueba de la unidad no es tener un 100% de éxito, el punto es encontrar y corregir errores en el código. No hacer pruebas es una forma fácil de tener un 100% de éxito, pero eso no es muy beneficioso para el proyecto.

    
respondido por el unholysampler 15.03.2011 - 16:29
1

Archivo de un error por cada falla, y tenga en cuenta que en el resultado de la prueba. Luego, si alguna vez se reúnen y corrigen el error, se pasan las pruebas y se eliminan del resultado de la prueba. Nunca ignores los problemas.

    
respondido por el SnoopDougieDoug 16.03.2011 - 04:29
-3

Cómo veo que TDD ha terminado con la implementación de pruebas para un código sin terminar, escriba las pruebas primero con el atributo [ExpectedException] o similar. Esto debería pasar inicialmente ya que el código incompleto no tendría ninguna lógica y escribiría un nuevo código de Excepción (). Aunque la excepción es incorrecta, al menos esto haría que las pruebas se aprobaran inicialmente y fueran adecuadas para el registro. Podemos olvidar una prueba ignorada, pero definitivamente podemos ordenar o completar el código incompleto. Cuando lo hagamos, automáticamente la prueba correspondiente que estaba esperando una excitación empezaría a fallar y le avisaría para que la arreglara. Esto puede implicar una ligera alteración de la prueba para deshacerse de ExpectException y en su lugar hacer afirmaciones reales. CI, Dev, probadores y clientes, ¿están contentos y en una situación en la que todos ganan?

    
respondido por el user211764 19.01.2016 - 15:36

Lea otras preguntas en las etiquetas