Oficio, calidad y equipos · Mixto

Pruebas: cuántas, cuáles y cuáles no valen la pena

En una línea: Invierte en una mayoría de pruebas que ejerciten tu lógica, algunas de integración, y muy pocas de extremo a extremo.

Tres capas

Unitarias. Rápidas, enfocadas, que corren en cada guardado. Ahí está la mayor parte del retorno.

Integración. Contra una base de datos real y colas reales. Atrapa lo que las unitarias pierden: esquema, transacciones, consultas.

Extremo a extremo. Caras y frágiles. Resérvelas para cinco a quince rutas críticas.

Qué vale la pena probar

Lógica de negocio con casos límite, cálculos, permisos, y lo que ya se rompió una vez. Cada bug corregido recibe una prueba: así la cobertura crece en los sitios correctos y no por porcentajes.

Qué no vale: código que solo mueve datos, y pruebas que simulan tanto que prueban la simulación y no el sistema.

Calidad de la prueba

Una buena prueba falla por un motivo claro y nombra qué se rompió. Una prueba inestable es peor que ninguna prueba: enseña al equipo a ignorar el rojo.

En profundidad

Separa las pruebas rápidas que corren en cada envío de una suite pesada que corre de noche. Y cuando una prueba falla de forma intermitente, trátala como un bug de alta prioridad: tolerar la inestabilidad borra en meses todo el valor de la suite.