¿Debo seguir registrando un error?

Question

Estoy trabajando en un conjunto de pruebas de regresión automatizadas para una aplicación que mantengo.Mientras desarrollaba la prueba de regresión automatizada, me encontré con un comportamiento que casi con certeza es un error.Entonces, por ahora, he modificado la prueba de regresión automatizada para no registrar una falla; quiero decir, está permitiendo deliberadamente que pase este mal comportamiento.

Entonces, me interesan las opiniones de otros en este sitio.Obviamente, agregaré un error a nuestro seguimiento de defectos para asegurarme de que este comportamiento de error se solucione.Pero, ¿existen razones de peso (de cualquier manera) para cambiar la prueba de regresión para indicar constantemente fallas o dejar la prueba de regresión rota y no fallar hasta que podamos corregir el comportamiento defectuoso?Pienso en esto como un 6 de una docena y media de otro tipo de preguntas, pero la hago aquí porque pensé que otros pueden verlo de manera diferente.

---

@Pablo Tomblin,

Para que quede claro: nunca he considerado eliminar la prueba;Simplemente estaba considerando modificar la condición de pasa/falla para permitir la falla sin que me la eche en cara cada vez que ejecuto la prueba.

Estoy un poco preocupado por las fallas repetidas por causas conocidas que eventualmente serán tratadas como advertencias en C++.Conozco desarrolladores que ven advertencias en su código C++ y simplemente las ignoran porque piensan que son ruido inútil.Me temo que dejar un fallo conocido en la suite de regresión podría hacer que la gente empiece a ignorar otros fallos, posiblemente más importantes.

Por cierto, para que no me malinterpreten, considero que las advertencias en C++ son una ayuda importante para crear código sólido, pero a juzgar por otros desarrolladores de C++ que he conocido, creo que soy una minoría.

Answer 1

Yo diría "¡diablos, sí!".El simple hecho es: ¿está fallando?¡Sí!Entonces debería registrarse.Prácticamente está comprometiendo sus pruebas al permitir que se apruebe una prueba fallida.

Una cosa que me preocuparía personalmente es que si hiciera esto y me hundiera, es posible que el "parche" no se elimine, lo que significa que incluso después de una "corrección de error", el error aún puede permanecer.

Déjelo ahí, actualice las notas de su proyecto, tal vez incluso reduzca la gravedad (si es posible), pero ciertamente no rompa lo que busca elementos rotos;)

Answer 2

Si dejas de probarlo, ¿cómo sabrás cuándo se ha solucionado y, lo que es más importante, cómo sabrás si se vuelve a estropear?Estoy en contra de eliminar la prueba, porque es probable que te olvides de volver a agregarla.

Answer 3

Agregamos una función de "posponer" a nuestras pruebas unitarias.Esto permitió anotar una prueba con un atributo que básicamente decía "ignorar fallas durante X semanas a partir de esta fecha".Los desarrolladores podían anotar una prueba que sabían que no se solucionaría por un tiempo con esto, pero no requería ninguna intervención en el futuro para volver a habilitarla manualmente, la prueba simplemente volvería a aparecer en el conjunto de pruebas en el momento designado.

Answer 4

Debería seguir siendo un fracaso si no hace lo que se esperaba.

De lo contrario, es demasiado fácil ignorarlo.Mantenga las cosas simples: funciona o no.Fracaso o éxito :)

--Kevin Fairchild

Answer 5

Si bien estoy de acuerdo con la mayor parte de lo que dijo Paul, el otro lado del argumento sería que las pruebas de regresión, estrictamente hablando, se supone que prueban cambios en el comportamiento del programa, no cualquier error antiguo.Se supone que deben avisarte específicamente cuando has roto algo que solía funcionar.

Creo que esto se reduce a qué otros tipos de pruebas se ejecutan en esta aplicación.Si tiene algún tipo de sistema de prueba unitaria, tal vez ese sea un lugar más apropiado para esta prueba, en lugar de la prueba de regresión (al menos hasta que se solucione el error).Sin embargo, si las pruebas de regresión son sus únicas pruebas, probablemente dejaría la prueba en su lugar.

Answer 6

Si bien es mejor que las pruebas fallen cuando hay errores, esta suele ser una opción poco práctica.Cuando se agrega una prueba a un área por primera vez, es particularmente fácil quedar atrapado en los errores que uno descubre y, por lo tanto, no completar el objetivo principal.Además, las pruebas que fallan durante mucho tiempo se vuelven ruidosas y cada vez más fáciles de ignorar.

Escribir pruebas fallidas es parte de corregir errores y solo es realmente importante cuando corregir esos errores es importante.Esto debe estar determinado por su producto actual y sus prioridades de calidad.Si produce pruebas como efecto secundario de algún otro esfuerzo, está bien, pero no debe permitir que lo distraiga de sus prioridades reales.

Recomendaría detectar cualquier error mientras se mejoran las pruebas de advertencias y se presentan los errores contra ellas.Es un enfoque amplio que lo ayudará a completar la tarea actual y al mismo tiempo utilizará lo que aprenda.Luego, las pruebas pueden convertirse fácilmente en fallas reales cuando se programa la corrección de los errores.

A diferencia de otros encuestados, creo que las fallas son tan fáciles de ignorar como las advertencias, y el costo de capacitar a su equipo para ignorar las fallas es demasiado alto como para permitir que esto suceda.Si produce pruebas fallidas como parte de este esfuerzo, habrá destruido la utilidad de su conjunto de pruebas de regresión cuando la tarea era mejorarlo.

Answer 7

Tener un examen reprobado es algo irritante.Hay una diferencia entre código roto y código inacabado, y si la prueba debe abordarse de inmediato depende de qué circunstancia exponga esta prueba fallida.

Si está roto, deberías arreglarlo lo antes posible.Si no está terminado, ocúpese de ello cuando tenga tiempo.

En cualquier caso, claramente puedes vivir con que se comporte mal (por ahora), por lo que mientras el problema esté registrado, es mejor que no te moleste hasta que tengas tiempo de solucionarlo.