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.