¿Debo continuar registrándome una falla?

Question

Estoy trabajando en un conjunto de pruebas de regresión automática para una aplicación que mantengo. Al desarrollar la prueba de regresión automática, encontré un comportamiento que casi con seguridad es un error. Por lo tanto, por ahora, modifiqué la prueba de regresión automática para no registrar un error, es decir, deliberadamente, permite que este mal comportamiento pase.

Por lo tanto, estoy interesado en las opiniones de los demás en este sitio. Obviamente, agregaré un error a nuestro seguimiento de defectos para asegurarme de que este comportamiento de error se solucione. Pero, ¿hay alguna razón convincente (de cualquier forma) para cambiar la prueba de regresión para indicar fallas constantemente o dejar la prueba de regresión rota y no tener una falla hasta que podamos llegar a corregir el comportamiento defectuoso? Pienso en esto como 6 de una y media docena del otro tipo de pregunta, pero pregunto aquí porque pensé que otros podrían verlo de manera diferente.

---

@ Pablo Tomblin,

Para que quede claro - nunca he considerado la eliminación de la prueba; Simplemente estaba considerando modificar la condición de aprobación/falla para permitir la falla sin que me la arrojen a la cara cada vez que ejecuto la prueba.

Estoy un poco preocupado por las repetidas fallas de causas conocidas que eventualmente se tratan como advertencias en C++. Conozco desarrolladores que ven las advertencias en su código C++ y simplemente las ignoran porque creen que son solo un ruido inútil. Me temo que dejar una falla conocida en el conjunto de regresión podría hacer que las personas empiecen a ignorar otras fallas, posiblemente más importantes.

BTW, para que no me malinterpreten, considero que las advertencias en C++ son una ayuda importante en la elaboración de 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 "¡demonios, sí!". El simple hecho es, ¿está fallando? ¡Sí! Entonces debería ser registrado. Estás prácticamente comprometiendo tus pruebas al permitir que pase una prueba fallida.

Una cosa que me preocuparía personalmente, es que si lo hice y me metí debajo de un autobús, entonces el "parche" podría no eliminarse, lo que significa que incluso después de una "corrección de error" el error puede permanecer.

dejarlo en, actualizar sus notas del proyecto, tal vez incluso mover la gravedad hacia abajo (si es posible), pero sin duda no te romper lo que está comprobando si hay cosas rotas;)

Answer 2

Si deja de probarlo, ¿cómo va a saber cuándo se solucionó y, lo que es más importante, cómo va a saber si se rompe nuevamente? Estoy en contra de sacar la prueba, porque es probable que olvide volver a agregarla.

Answer 3

debe seguir siendo un fracaso si no es haciendo lo que se esperaba

De lo contrario, es muy fácil de ignorar. Mantenga las cosas simples, funciona o no funciona. Fallan o el éxito :)

- Kevin Fairchild

Answer 4

Tener una prueba no es una especie de rejilla. Existe una diferencia entre el código roto y el código sin terminar, y si la prueba debe abordarse inmediatamente depende de qué circunstancia expone esta prueba fallida.

Si está roto, debe solucionarlo más temprano que tarde. Si no está terminado, enfréntalo cuando tengas tiempo.

En cualquier caso, claramente se puede vivir con un comportamiento incorrecto (por ahora), por lo que siempre que el problema se registre es mejor que no lo fastidie hasta que tenga tiempo de arreglarlo.

Answer 5

Aunque estoy de acuerdo con la mayoría de lo que dijo Paul, el otro lado del argumento sería que las pruebas de regresión, estrictamente hablando, se supone que prueban los cambios en el comportamiento del programa, no solo cualquier error anterior. Se supone que específicamente deben decirte cuándo has roto algo que solía funcionar.

Creo que esto se reduce a lo que otros tipos de pruebas se ejecutan en esta aplicación. Si tiene algún tipo de sistema de pruebas unitarias, tal vez ese sea un lugar más apropiado para esta prueba, en lugar de en 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é la prueba en su lugar.

Answer 6

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

Answer 7

Si bien es mejor hacer que las pruebas fallen cuando hay errores, esto a menudo es una elección poco práctica. La primera vez que se agrega una prueba a un área, es particularmente fácil atascarse en los errores que uno descubre y, por lo tanto, no terminar el objetivo principal. Además, las pruebas de larga duración se vuelven mucho ruido, más fácil y más fácil de ignorar.

Escribir pruebas de falla es parte de corregir errores, y solo es realmente importante cuando corregir esos errores es importante. Esto debe ser determinado por su producto actual y prioridades de calidad. Si produce pruebas como un efecto secundario de algún otro esfuerzo, eso es bueno, pero no debe permitirse que lo distraiga de sus prioridades reales.

Recomendaría hacer que se descubrieran errores mientras mejoraba las pruebas de advertencias y los errores de archivo. Es un enfoque de amplitud que lo guiará a través de la tarea actual mientras que también utiliza lo que aprende. Las pruebas pueden convertirse fácilmente en fallas reales cuando los errores están programados para la reparación.

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 para permitir que ocurra. Si produce pruebas fallidas como parte de este esfuerzo, habrá destruido la utilidad de su conjunto de pruebas de regresión cuando la tarea lo estaba mejorando.