Los tests en la cadena de integración

Su pipeline de integración tarda veintiséis minutos. Un desarrollador abre una pull request, lanza la ejecución y se pone con otra cosa. Media hora después, un test de extremo a extremo está en rojo; lo relanza sin mirar, porque «ese falla de vez en cuando». Cincuenta minutos después del primer commit, la fusión pasa. Con cinco pull requests al día, el equipo ha perdido cuatro horas de espera y, sobre todo, el hábito de leer los fallos.

Ese es el punto de inflexión que hay que evitar, y no tiene nada que ver con la calidad de los tests considerados individualmente. Una suite es útil mientras su veredicto llegue lo bastante rápido como para seguir ligado al cambio que la ha desencadenado, y mientras un test en rojo signifique realmente «algo está roto». Pasados unos diez minutos, la gente cambia de contexto. Pasados unos cuantos fallos aleatorios tolerados, deja de leer. Esta lección trata, por tanto, de dos magnitudes: el tiempo de ejecución y la tasa de falsos fallos. Todo lo demás se deriva de ellas.

Dividir la ejecución en etapas

No lance todo al mismo tiempo. Los tests rápidos deben dar su veredicto antes de que arranquen los lentos, para fallar pronto y liberar los agentes.