¿Debería romper intencionalmente la compilación cuando se encuentra un error en la producción?

Me parece razonable que si los usuarios finales encuentran un error grave en la producción, se debe agregar una prueba unitaria fallida para cubrir ese error, rompiendo así la compilación intencionalmente hasta que se solucione el error. Mi razón para esto es que la compilación debería haber fallado todo el tiempo , pero no se debió a una cobertura de prueba automatizada inadecuada.

Varios de mis colegas no están de acuerdo con decir que una prueba de unidad que falla no debe registrarse. Estoy de acuerdo con este punto de vista en términos de prácticas normales de TDD, pero creo que los errores de producción deben manejarse de manera diferente, después de todo, ¿por qué querría permitir ¿Una construcción para tener éxito con defectos conocidos?

¿Alguien más tiene estrategias comprobadas para manejar este escenario? Entiendo que romper la compilación intencionalmente puede ser perjudicial para otros miembros del equipo, pero eso depende completamente de cómo esté utilizando las ramas.

Nuestra estrategia es:

Verifica en una prueba que falla, pero anótala con @Ignore("fails because of Bug #1234").

De esa manera, la prueba está ahí, pero la construcción no se rompe.

Por supuesto, observa la prueba ignorada en el error db, por lo que @Ignorese elimina una vez que se corrige la prueba. Esto también sirve como una verificación fácil para la corrección de errores.

El punto de romper la construcción en las pruebas fallidas no es presionar al equipo de alguna manera, es alertarlos de un problema. Una vez que el problema se identifica y se archiva en la base de datos de errores, no tiene sentido hacer que se ejecute la prueba para cada compilación: sabe que fallará.

Por supuesto, el error aún debe corregirse. Pero programar la solución es una decisión comercial y, por lo tanto, no es realmente una preocupación del desarrollador ... Para mí, una vez que se registra un error en la base de datos de errores, ya no es mi problema, hasta que el cliente / propietario del producto me dice que quiere que se solucione .

¿Por qué querría permitir que una compilación tenga éxito con defectos conocidos?

Porque a veces, tienes limitaciones de tiempo. O el error es tan pequeño que realmente no vale la pena retrasar el envío del producto por unos días necesarios para probarlo y arreglarlo.

Además, ¿cuál es el punto de romper la compilación intencionalmente cada vez que encuentras un error? Si lo encontró, arréglelo (o asígnelo a la persona que lo arreglará), sin molestar a todo su equipo. Si desea recordar corregir un error, debe marcarlo como muy importante en su sistema de seguimiento de errores.

Las pruebas están ahí para garantizar que no (re) presente problemas. La lista de pruebas fallidas no sustituye a un sistema de seguimiento de errores. Hay una cierta validez en el POV de que las pruebas fallidas no son solo una indicación de errores, sino que también son una indicación de falla en el proceso de desarrollo (desde el descuido hasta la dependencia mal identificada).

"Romper la compilación" significa evitar que una compilación se complete con éxito . Una prueba fallida no hace eso. Es una indicación de que la compilación tiene defectos conocidos, lo cual es exactamente correcto.

La mayoría de los servidores de compilación rastrean el estado de las pruebas a lo largo del tiempo y asignarán una clasificación diferente a una prueba que ha fallado desde que se agregó frente a una regresión (prueba que solía pasar y ya no lo hace), y también detectan la revisión en la que La regresión tuvo lugar.

Yo diría que la prueba de falla debe agregarse, pero no explícitamente como "una prueba de falla".

Como @BenVoigt señala en su respuesta , una prueba fallida no necesariamente "rompe la construcción". Supongo que la terminología puede variar de un equipo a otro, pero el código aún se compila y el producto aún puede enviarse con una prueba fallida.

Lo que debes preguntarte en esta situación es:

¿Cuáles son las pruebas destinadas a lograr?

Si las pruebas están ahí solo para que todos se sientan bien con el código, entonces agregar una prueba fallida solo para que todos se sientan mal por el código no parece productivo. Pero entonces, ¿qué tan productivas son las pruebas en primer lugar?

Mi afirmación es que las pruebas deben ser un reflejo de los requisitos comerciales . Por lo tanto, si un "error" se ha encontrado que indica un requisito no se cumple adecuadamente, entonces es también una indicación de que las pruebas no reflejan correctamente o totalmente los requerimientos del negocio.

Ese es el error que se debe solucionar primero. No estás "agregando una prueba fallida". Estás corrigiendo las pruebas para ser un reflejo más preciso de los requisitos del negocio. Si el código no pasa esas pruebas, eso es algo bueno. Significa que las pruebas están haciendo su trabajo.

La prioridad de arreglar el código será determinada por la empresa. Pero hasta que se arreglen las pruebas, ¿se puede determinar realmente esa prioridad? El negocio debe estar armado con el conocimiento de exactamente qué está fallando, cómo está fallando y por qué está fallando para poder tomar sus decisiones con prioridad. Las pruebas deberían indicar esto.

Tener pruebas que no pasan completamente no es algo malo. Crea un gran artefacto de problemas conocidos que deben priorizarse y manejarse en consecuencia. Sin embargo, tener pruebas que no prueban completamente es un problema. Pone en duda el valor de las pruebas mismas.

Para decirlo de otra manera ... La construcción ya está rota. Todo lo que está decidiendo es si llamar o no la atención sobre ese hecho.

En nuestro equipo de automatización de pruebas, verificamos las pruebas fallidas siempre que fallen debido a un defecto en el producto en lugar de un defecto en la prueba. De esa forma tenemos pruebas para el equipo de desarrollo de que, bueno, lo rompieron. Romper la compilación está muy mal visto, pero eso no es lo mismo que registrarse en pruebas perfectamente compilables pero que fallan.

Escribir una prueba que sabe que fallará hasta que se solucione el error es una buena idea, es la base de TDD.

Romper la construcción es una mala idea. ¿Por qué? Porque significa que nada puede avanzar hasta que se arregle. Esencialmente bloquea todos los demás aspectos del desarrollo.

Ejemplo 1
¿Qué sucede si su aplicación es grande, con muchos componentes? ¿Qué pasa si esos componentes son trabajados por otros equipos con su propio ciclo de lanzamiento? ¡Difícil! ¡Tienen que esperar su corrección de errores!

Ejemplo 2
¿Qué sucede si el primer error es difícil de solucionar y encuentra otro error con mayor prioridad? ¿También rompes la compilación para el segundo error? Ahora no puedes construir hasta que ambos estén arreglados. Has creado una dependencia artificial.

No hay una razón lógica por la que la falla de una prueba deba detener una compilación. Esta es una decisión que el equipo de desarrollo debe tomar (quizás con una discusión administrativa) sopesando los pros y los contras de lanzar una compilación con errores conocidos. Esto es muy común en el desarrollo de software, casi todo el software principal se lanza con al menos algunos problemas conocidos.

Depende del papel que se supone que juegan las pruebas y de cómo se supone que sus resultados afectan el sistema / proceso de compilación adoptado. Mi comprensión de romper la compilación es la misma que la de Ben, y al mismo tiempo, no debemos verificar a sabiendas el código que rompe las pruebas existentes. Si esas pruebas llegaron "más tarde", podría estar "bien" ignorarlas solo para que sea menos innecesariamente perjudicial para los demás, pero encuentro esta práctica de ignorar las pruebas reprobadas (para que parezcan aprobadas) bastante inquietante (especialmente para pruebas unitarias), a menos que haya una manera de indicar tales pruebas como ni rojo ni verde.

Depende del error, por supuesto, pero en general si algo salió mal que no se identificó durante las pruebas manuales o automáticas, eso implica que hay una brecha en su cobertura. Definitivamente, me gustaría animar a descubrir la causa raíz y poner un caso de prueba de unidad además del problema.

Si se trata de un problema de producción que está planificado para una reparación en caliente de una rama de mantenimiento, también debe asegurarse de que la solución funcione en la línea principal y que un desarrollador no pueda eliminar la solución por error con una resolución de conflicto de fusión excesivamente entusiasta .

Además, dependiendo de su política de lanzamiento, la presencia de pruebas unitarias recientemente actualizadas puede ayudar a confirmar que un desarrollador realmente ha solucionado el problema, en lugar de simplemente cambiarlo [(¿el problema o las pruebas?)], Aunque esto depende de haber codificado el requisitos correctos en las nuevas pruebas unitarias.

Un problema al agregar una prueba de saber fallar a la compilación es que su equipo puede acostumbrarse a ignorar las pruebas fallidas porque esperan que la compilación falle. Depende de su sistema de compilación, pero si una prueba fallida no siempre significa "algo acaba de romperse", entonces es fácil prestar menos atención a las pruebas fallidas.

No quieres ayudar a tu equipo a tener esa mentalidad.

Por lo tanto, estoy de acuerdo con Sleske en que debe agregar la prueba, pero marcarla como 'ignorada' a los efectos de la compilación automática, hasta que se solucione el error.

Si bien creo que de alguna manera deberías 'revisar' el error como prueba, para que cuando lo arregles no vuelva a ocurrir, y de alguna manera priorizarlo, creo que es mejor no romper la compilación (/ las pruebas) . La razón es que las confirmaciones de ruptura de compilación posteriores se ocultarán detrás de su prueba interrumpida. Entonces, al registrar una prueba rota para este error, usted exige que todo el equipo deje de lado su trabajo para solucionar este error. Si eso no sucede, puede terminar rompiendo confirmaciones que no son rastreables como tales.

Por lo tanto, diría que es mejor cometerlo como una prueba pendiente y hacer que sea una prioridad en su equipo no tener pruebas pendientes.

Otra opción es verificar la prueba fallida en una rama separada en su sistema de control de fuente. Dependiendo de sus prácticas, esto puede ser factible o no. A veces abrimos una nueva rama para el trabajo en curso, como arreglar un error que no es trivial.