¿Cómo creo un entorno donde la fijación de pruebas se considera una prioridad?

Soy ingeniero de software en una empresa mediana. Tenemos una plataforma de prueba bastante robusta que se ejecuta en TeamCity. Realiza pruebas unitarias en cada registro y una prueba unitaria diaria / BVT.

El problema es que tenemos una gran cantidad de pruebas unitarias rotas.

Muy a menudo, menciono la inutilidad de las pruebas unitarias si se rompen constantemente y no se mantienen. No poder ver si un cambio ha causado una regresión elimina la mayor parte del valor de una plataforma de prueba unitaria.

Me gustaría plantar una semilla que cree una cultura de buenos hábitos: arreglar las pruebas cuando se rompen, verlas como valiosas, priorizar la fijación de las pruebas junto con otros trabajos.

He intentado el soborno (¡productos horneados!), Simplemente preguntando y hablando con los líderes del equipo. Todos dicen que es una buena idea, pero veo que soy el único que hace algo al respecto.

¿Cuál es la mejor manera de comenzar a alentar a otros a corregir sus pruebas y priorizar la corrección de pruebas dentro de sus sprints?

Si hay una forma menos subjetiva de preguntar esto, me complacería aceptar cualquier consejo.

— Codeman
fuente

pistola nerf automática dirigida al tipo que rompe la construcción ...

— Ratchet Freak

De hecho, tenemos una pistola nerf automática ... pero la construcción no está rota, solo las pruebas de la unidad :)

— Codeman

Romper las pruebas unitarias debería implicar romper la construcción. ;)

— Jeroen Vannevel

@ Ӎσᶎ: La aceptación es importante, pero no puede obtener la aceptación para resolver un problema hasta que las personas realmente lo sepan . En este caso, la necesidad de aceptación solo proviene inicialmente de los líderes y gerentes de equipo. La aceptación del desarrollador puede llegar más tarde y, en general, lo hará, naturalmente, cuando el sistema de compilación se haya configurado para que los desarrolladores individuales paguen por sus propios errores.

— Aaronaught

Si las rosquillas fallaron, estás tostado. :-)

— Ross Patterson

Respuestas:

Haz que sea imposible liberar algo sin arreglar las pruebas.

Fallar la compilación si alguna prueba falla.
Fallar la compilación si se ignora alguna prueba.
Falla la compilación si la cobertura de la prueba cae por debajo de un cierto nivel (por lo que las personas no pueden simplemente eliminar las pruebas para evitarlo).
Use el servidor CI para realizar sus compilaciones de lanzamiento y solo permita que las compilaciones de la caída de compilación del servidor se promocionen a UAT / staging / production / lo que sea.

El hecho es que, si su compilación se rompe durante más de 15 minutos a la vez (y eso incluye pruebas fallidas), entonces no está haciendo una integración continua .

La "opción nuclear" es hacer que su servidor de control de origen rechace las confirmaciones / registros de cualquier usuario que no sea el que rompió la compilación. Obviamente, un administrador debe poder anular esto temporalmente si dicha persona se va de vacaciones, pero si todos saben que todo el equipo está jodido hasta que arreglen sus pruebas, lo resolverán muy rápido.

Una buena política (que es aún mejor cuando está automatizada) es revertir la fuente a la última confirmación estable conocida después de 15 minutos de la falla de compilación. En otras palabras, si no puede solucionarlo, o no sabe qué causó la ruptura de la compilación o la prueba, revísela y trabaje localmente hasta que se resuelva; nunca haga que otros desarrolladores muevan sus pulgares mientras usted trabaja problema que no les importa.

PD Si ya tiene muchas pruebas fallidas, puede usar un "umbral final" en CI. Configúrelo para que la compilación solo falle si hay más fallas de prueba que la última vez. Esto, junto con una regla de cobertura, obligará a los desarrolladores a mejorar eventualmente la situación de prueba si quieren seguir trabajando.

PPS Me doy cuenta de que esto puede parecer draconiano para algunos, pero todo depende de tu cultura. Si llega a un punto en el que la gente simplemente no deja la construcción rota o las pruebas fallan (mi equipo casi nunca lo hace, aunque ocasionalmente tengo que recordarles), entonces no necesita continuar con el conjunto más estricto de reglas. Aunque IMO siempre debe fallar la compilación en una prueba de unidad rota. Las pruebas de integración / navegador a veces pueden fallar.

— Aaronaught
fuente

Si bien todas sus sugerencias técnicas son útiles, creo que la parte más valiosa de su respuesta es que "es toda su cultura" porque más que un problema de disciplina, es un problema de utilidad percibida de la prueba. Prefiero ponerlo al frente que en un PPS

— user40989

@ user40989: te escucho. Sin embargo, la cultura es algo que debes cultivar. Si desea que las personas entiendan la importancia de las pruebas, a veces debe hacerlo para que las personas no puedan ignorarlas. Una vez que las personas se acostumbren a un alto nivel de cobertura de código y pruebas ecológicas, no querrán regresar, y luego sus propios desarrolladores lo harán cumplir para los nuevos reclutas. Bueno, ojalá. Un líder de equipo anal-retentivo y / o maestro de construcción y / o gerente ayuda. :)

— Aaronaught

FWIW: Todo nuestro proceso de lanzamiento ahora está automatizado y la gente no pensaría en tener pruebas rotas. El líder del equipo se fusiona para dominar, luego comienza una compilación de lanzamiento y envía una solicitud de promoción a los administradores de sistemas que literalmente presionan un botón para implementar desde los artefactos de compilación y ejecutar pruebas automatizadas de navegador y API. Nadie se queja de este proceso, ya que ahorra tiempo : solíamos pasar 2 semanas preocupados por un lanzamiento, ahora es básicamente una onda manual. Esto es lo que quiero decir con cultivar la cultura: todos saben que los 2 minutos adicionales para arreglar una prueba ahorrarán 2 horas más tarde.

— Aaronaught

Las pruebas de unidades que fallan no son el problema. Son un síntoma .

El verdadero problema está en la cultura. Necesitas pisar suavemente: aquí hay dragones . No puedes cambiar la cultura por ti mismo, y ser la rueda chirriante, al final, te convertirá en un paria. Literalmente.

Sugiero que si intentas encontrar a una persona mayor para defender la causa y liderar el camino. Si eso falla, intente plantearlo en una reunión general de desarrolladores, sin señalar ni llamar. Otra alternativa es asumir la responsabilidad de hacer un trabajo adecuado: solo arregle algunas pruebas más cada vez que realice un check-in. Mantenga un cuadro en la pared que muestre cuántas pruebas fallan con el tiempo. Otros lo verán: tal vez opten.

No hay una respuesta fácil.

— andy256
fuente

Ser la rueda chirriante me hizo liderar el equipo. Tal vez hubo algo mal con tu chillido? Sin embargo, con toda seriedad, eso habla de un problema cultural muy diferente , no con el equipo de desarrollo sino con la administración de la empresa. Si la respuesta de la gerencia a un fuego ardiente es ponerse gafas de sol, entonces salga de allí. Pero si en realidad es una tienda de desarrollo , a diferencia de un departamento de TI empresarial que produce software de un centro de costos, es bastante probable que los gerentes se preocupen por cosas como con qué frecuencia y seguridad puede lanzar al mercado.

— Aaronaught