Pruebas automáticas: qué merece la pena comprobar
Una prueba que falla a veces es peor que no tenerla: enseña al equipo a ignorar el color rojo.
La cobertura mide poco
El porcentaje de líneas de código ejecutadas por las pruebas es fácil de medir, y por eso se convierte en objetivo. Pero mide ejecución, no comprobación: una prueba que recorre una función sin verificar nada suma cobertura igual que una buena.
Fijar un umbral de cobertura produce, con notable fiabilidad, pruebas escritas para alcanzarlo.
Qué distingue una prueba útil
- Comprueba comportamiento, no implementación. Si refactorizar rompe la prueba sin cambiar el comportamiento, la prueba estorba.
- Falla por una sola razón. Cuando falla, se sabe qué mirar.
- Es determinista. Mismo código, mismo resultado, siempre.
- Es rápida, o vive fuera del flujo rápido.
- Cubre un caso que puede ocurrir, no una combinación imposible.
Las pruebas intermitentes
Una prueba que falla una de cada veinte ejecuciones sin motivo aparente hace más daño que su ausencia: enseña al equipo que el rojo no significa nada. A partir de ahí, un fallo real pasa desapercibido.
| Causa | Síntoma |
|---|---|
| Dependencia del tiempo | Falla a medianoche o en otra zona horaria |
| Orden de ejecución | Falla sólo al ejecutarse en paralelo |
| Estado compartido | Falla la segunda vez seguida |
| Espera fija en lugar de condición | Falla cuando la máquina va lenta |
| Servicio externo real | Falla cuando el otro sistema tiene un mal día |
| Datos aleatorios | Falla con un valor concreto, una vez al mes |
Datos de prueba
La forma más rápida de tener datos realistas es copiar producción, y es también una fuente frecuente de incidentes de protección de datos: copias de datos personales en entornos con menos control y más gente con acceso.
Las alternativas —datos sintéticos, subconjuntos anonimizados— cuestan más de preparar y evitan un problema que es caro de explicar después.
