¿Debo interrumpir intencionalmente la compilación cuando se encuentra un error en producción?

Nuestra estrategia es:

Comprueba una prueba que falla, pero haz una anotación con @Ignore("fails because of Bug #1234") .

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

Por supuesto que observa la prueba ignorada en la base de datos de errores, por lo que se elimina el @Ignore una vez que se soluciona la prueba. Esto también sirve como una comprobación fácil para la corrección de errores.

El punto de romper la compilación en las pruebas que fallan no es presionar al equipo, sino alertarlo de un problema. Una vez que el problema se identifica y se archiva en la base de datos de errores, no tiene sentido que se ejecute la prueba para cada compilación, usted sabe que fallará.

Por supuesto, el error todavía debe ser arreglado. Pero programar la solución es una decisión de negocios, y por lo tanto no es realmente una preocupación del desarrollador ... Para mí, una vez que se presenta 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 restricciones de tiempo. O bien, el error es tan pequeño que realmente no vale la pena retrasar el envío del producto durante algunos días necesarios para realizar pruebas de unidad y solucionarlo.

Además, ¿qué sentido tiene romper la compilación intencionalmente cada vez que encuentre un error? Si lo encontró, repárelo (o cópielo a la persona que lo arreglará), sin molestar a todo el 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) introduzcas problemas. La lista de pruebas fallidas no es un sustituto para un sistema de seguimiento de errores. Existe 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 una falla en el proceso de desarrollo (desde el descuido hasta la dependencia mal identificada).

"Romper la compilación" significa para evitar que una compilación se complete con éxito . Una prueba que falla no hace eso. Es una indicación de que la construcción tiene defectos conocidos, lo que 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 estado fallando desde que se agregó contra una regresión (prueba que solía pasar y ya no lo hace), y también detecta la revisión en que tuvo lugar la regresión.

Argumentaría que la prueba que falla se debe agregar, pero no explícitamente como "una prueba que falla".

Como @BenVoigt señala en su respuesta , una prueba fallida no necesariamente "rompe la compilació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 deberías preguntarte en esta situación es,

  

¿Qué se supone que deben realizar las pruebas?

Si las pruebas están ahí solo para hacer que todos se sientan bien con el código, entonces agregar una prueba con fallas para que todos se sientan mal con 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 empresariales . Por lo tanto, si se ha encontrado un "error" que indica que un requisito no se cumple correctamente, es también una indicación de que las pruebas no reflejan de manera adecuada o completa los requisitos comerciales.

Ese es el error que se debe corregir primero. No estás "añadiendo una prueba fallida". Usted está corrigiendo las pruebas para que sea un reflejo más preciso de los requisitos comerciales. Si el código no pasa esas pruebas, eso es bueno. Significa que las pruebas están haciendo su trabajo.

La prioridad de arreglar el código debe ser determinada por el negocio. Pero hasta que las pruebas sean fijas, ¿se puede determinar realmente esa prioridad? El negocio debe estar armado con el conocimiento de qué es exactamente lo que está fallando, cómo está fallando y por qué está fallando para tomar sus decisiones sobre la prioridad. Las pruebas deben 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 sean completamente test es un problema. Pone en duda el valor de las pruebas en sí.

Para decirlo de otra manera ... La construcción ya está rota. Todo lo que está decidiendo es si debe o no llamar 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 manera tenemos pruebas para el equipo de desarrollo que oye, lo rompieron. Romper la construcción es muy mal visto, pero eso no es lo mismo que verificar las pruebas perfectamente compilables pero que fallan.

Escribir una prueba que sepa 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 moverse hasta que se arregle. Básicamente bloquea todos los demás aspectos del desarrollo.

Ejemplo 1
¿Qué pasa 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 por su corrección de errores!

Ejemplo 2
¿Qué sucede si el primer error es difícil de solucionar y encuentra otro con una prioridad más alta? ¿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 fallar una prueba debería detener una compilación. Esta es una decisión que el equipo de desarrollo debe tomar (quizás con una discusión de la gerencia) 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 de la función que se supone que deben desempeñar 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 construcción es la misma que la de Ben, y al mismo tiempo no deberíamos 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 hacerlas menos innecesariamente perjudiciales para los demás, pero me parece que esta práctica de ignorar las pruebas fallidas (para que parezcan aprobadas) es bastante perturbadora (especialmente) para pruebas unitarias), a menos que haya una manera de indicar tales pruebas como rojo o verde.

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

Si se trata de un problema de producción que está planificado para una corrección de una rama de mantenimiento, también debe asegurarse de que la corrección funcione en la línea principal, y que un desarrollador no pueda ignorar erróneamente la corrección con una celosía excesiva. fusionar la resolución de conflictos.

Además, dependiendo de su política de lanzamiento, la presencia de pruebas unitarias recién actualizadas puede ayudar a confirmar que un desarrollador realmente solucionó el problema, en lugar de simplemente cambiarlo [(¿el problema o las pruebas?)], aunque esto depende de Haber codificado los 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 que falla no siempre significa "algo se acaba de romper", entonces es fácil prestar menos atención a las pruebas que fallan.

No quieres ayudar a tu equipo a entrar en esa mentalidad.

Entonces, estoy de acuerdo con Sleske en que deberías agregue la prueba, pero márquela como 'ignorada' para el propósito de la compilación automática, hasta que se solucione el error.

Aunque creo que, de alguna manera, debería 'controlar' el error como prueba, para que cuando lo arregle no vuelva a suceder, y de alguna manera priorizarlo, creo que es mejor no romper la compilación (/ los exámenes). La razón es que, posteriormente, las compilaciones de ruptura de la construcción se ocultarán detrás de la prueba rota. Entonces, al revisar una prueba rota para este error, usted exige que todo el equipo haga su trabajo a un lado para corregir este error. Si eso no ocurre, podría terminar con comillas de ruptura que no son rastreables como tales.

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

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