¿Eliminar o comentar las pruebas JUnit que no funcionan?

Question

Actualmente estoy construyendo un script de compilación CI para una aplicación heredada. Hay pruebas esporádicas de JUnit disponibles y voy a integrar una ejecución JUnit de todas las pruebas en la construcción de CI. Sin embargo, me pregunto qué hacer con las fallas de 100''ish que estoy encontrando en las pruebas JUnit no mantenidas. ¿Me:

1) Comentario a cabo, ya que parecen tener razonable, si no mantenido, la lógica de negocio en ellos con la esperanza de que alguien finalmente los uncomments y los fija

2) eliminarlos como su poco probable que alguien los arreglaré y el código comentado solo será ignorado o será un desorden para siempre

3) Localice a aquellos que han dejado este lío en mis manos y golpéelos con las impresiones del código (que debido a el olor a largo plazo será lo suficientemente adecuado para la tarea) mientras predica los beneficios de una base de código bien probada y probada por unidad

Answer 1

• Coméntelos para que se puedan solucionar más adelante.
• Generar informes de cobertura de prueba (con Cobertura por ejemplo). Los métodos que se suponía que estarían cubiertos por las pruebas que usted comentó serán indicados como no cubiertos por las pruebas.

Answer 2

Si se compilan pero fallan: déjelos. Eso le proporcionará un buen historial de mejoras en las pruebas con el tiempo al usar CI. Si las pruebas no compilan pero rompen la construcción, coméntelas y pida a los desarrolladores que las solucionen.

Esto, obviamente, no excluye el uso de la opción 3 (golpeándolos en la cabeza), debe hacerlo de todos modos, independientemente de lo que haga con las pruebas.

Answer 3

Si usa Junit 4 puede anotar esas pruebas con @Ignore annotation.

Si usa JUnit 3 puede simplemente cambiar el nombre de las pruebas para que no comiencen con test.

Además, intente reparar las pruebas de funcionalidad que está modificando para no ensuciar el código.

Answer 4

No conozco su puesto en la empresa, pero si es posible, déjelo en su lugar y registre los problemas como errores en su sistema de tickets. Deja que los desarrolladores lo arreglen o eliminen las pruebas.

Si eso no funciona, quítelos (tiene control de versión, ¿no?) Y cierre el ticket con un comentario como 'eliminó pruebas junit fallidas que aparentemente no serán reparadas' o algo un poco más cortés.

El punto es que las pruebas junit son código de aplicación y, como tal, deberían funcionar. Para eso se les paga a los desarrolladores. Si una prueba ya no es apropiada (algo que ya no existe ha sido probado), los desarrolladores deberían señalizarlo y eliminar la prueba.

Answer 5

Siga el principio no broken window y realice una acción para solucionar el problema. Si no puede corregir las pruebas, al menos:

1. Ignorelas de las pruebas unitarias (hay diferentes formas de hacerlo).
2. Ingrese tantos problemas como sea necesario y asigne personas para corregir las pruebas.

Entonces a prevenir tal situación suceda en el futuro, instale un tapón en similar a Hudson Game Plugin. A las personas se les asignan puntos durante la integración continua, p.

• -10 romper la acumulación < - el peor
• -1 romper una prueba
• 1 fijar una prueba
• etc.

herramienta realmente fresco para crear una sensación de responsabilidad sobre pruebas unitarias dentro de un equipo.

Answer 6

Definitivamente debe deshabilitarlos de alguna manera por el momento. Ya sea que se haga mediante comentarios, eliminación (suponiendo que puede recuperarlos del control de código fuente) o por otros medios depende de usted. No desea que estas pruebas fallidas sean un obstáculo para las personas que intentan enviar nuevos cambios.

Si hay pocas que crea que puede arreglarlas usted mismo, genial, hágalo. Si hay demasiados de ellos, me inclinaría a utilizar un enfoque de "crowdsourcing". Archive un error para cada prueba fallida. Si es posible, asigne estos errores a los propietarios/autores reales del código de prueba/probado, pero si eso es demasiado difícil de determinar, la selección aleatoria está bien siempre y cuando le diga a las personas que reasignen los errores que les fueron asignados incorrectamente. Luego anime a las personas a corregir estos errores ya sea dándoles una fecha límite o notificando periódicamente a todos sobre el progreso y alentándolos a corregir todos los errores.

Answer 7

Un sistema de CI que es rojo fijo es bastante inútil. El principal beneficio es mantener una barra de calidad, y eso se hace mucho más difícil si no hay transición para marcar una caída de calidad.

Por lo tanto, el esfuerzo inmediato debe ser desactivar las pruebas fallidas y crear un ticket de seguimiento/elemento de trabajo para cada una. Cada uno de ellos se resuelve sin embargo hacer triage: si a nadie le importa la prueba, deshágase de ella. Si la falla representa un problema que debe abordarse antes del envío, deje la prueba deshabilitada.

Una vez que se encuentre en este estado, ahora puede confiar en el sistema de CI para informarle que se requiere una acción urgente: deshacer el último cambio o poner a un equipo a arreglar el problema o lo que sea.

Answer 8

Las pruebas JUnit en su defecto indicar que, o bien

1. El código fuente sometida a ensayo se ha trabajado en las pruebas sin ser mantenidos. En este caso, definitivamente vale la pena considerar la opción 3 o
2. Tiene una falla real.

De cualquier forma que necesite corregir/revisar las pruebas/fuente. Como parece que su trabajo es crear el sistema de CI y no reparar las pruebas, en su posición dejaría una bomba de tiempo en las pruebas. Se puede llegar muy elegante con métodos anotados con JUnit 4 (algo así como @IgnoreUntil(date="2010/09/16")) y un corredor de encargo, por lo que o simplemente puede añadir una una sentencia if para la primera línea de cada prueba:

if (isBeforeTimeBomb()) { 
    return; 
    } 

Dónde isBeforeTimeBomb() puede simplemente verifique la fecha actual contra una fecha futura de su elección.Luego sigue los consejos de otros y notifica a tu equipo de desarrollo que la construcción es verde ahora, pero es probable que explote en X días, a menos que se repare la prueba de bombardeo de tiempo.