La pirámide, con números
Cuántas pruebas de cada tipo, cuánto deben tardar, y cómo se decide qué probar cuando el tiempo es limitado.
La proporción
Y el presupuesto que importa es el primero: si las pruebas rápidas tardan más de unos segundos, dejan de ejecutarse mientras se programa — y una prueba que solo se ejecuta en la construcción automática vale la mitad.
Qué probar con tiempo limitado
Y lo que va al final: el camino feliz de lo que se usa constantemente, que ya está cubierto por el uso.
Los dos primeros son específicos de escritorio y suelen estar por debajo de donde deberían en proyectos que traen costumbres de otro tipo de software.
Cuándo se ejecuta cada cosa
Lo del nivel 67.3, con las pruebas:
- Las rápidas, mientras programas — y por eso el presupuesto de segundos.
- Las de comandos, en cada cambio subido.
- Las de extremo a extremo, en la rama principal o antes de publicar.
- Y las manuales, antes de publicar. Niveles 51.5 y 61.4.
La suite que se degrada
Cuatro señales de que hay que hacer algo:
- Tarda demasiado y la gente deja de ejecutarla.
- Falla a veces sin motivo. Nivel 71.2: pruebas frágiles. Y una prueba que falla aleatoriamente es peor que no tenerla, porque enseña a ignorar los fallos.
- Nadie la arregla cuando falla, y se acumulan pruebas desactivadas.
- Y no ha detectado nada en mucho tiempo — que puede significar que el código es estable o que las pruebas no cubren lo que cambia.
La segunda es la más urgente: una prueba intermitente hay que arreglarla o quitarla, nunca dejarla.