Un equipo reducido no puede cubrirlo todo. Esta guía define dónde invertir las pruebas cuando el tiempo es el recurso escaso.
La cobertura total no es el objetivo
Perseguir un porcentaje alto de cobertura produce baterías enormes que tardan en ejecutarse, se rompen ante cualquier cambio y terminan desactivadas. El objetivo no es cubrir líneas, sino reducir el riesgo de romper lo que importa.
Un conjunto pequeño de pruebas bien elegidas, que se ejecuta en minutos y en el que el equipo confía, vale más que una batería exhaustiva que nadie mira.
Dónde invertir primero
Lo que no compensa automatizar al inicio
Interfaces que aún están cambiando de forma. Flujos completos de extremo a extremo con muchas dependencias, que fallan por motivos ajenos al código y erosionan la confianza del equipo en la batería.
Estos casos se cubren mejor con verificación manual guiada por una lista de comprobación, hasta que la funcionalidad se estabilice.
Ejecutarlas donde importa
Una batería que solo corre en la máquina de quien la escribió no protege a nadie. Debe ejecutarse de forma automática ante cada cambio propuesto y bloquear la integración cuando falla.
Ese único cambio de proceso convierte las pruebas de un ejercicio de buena voluntad en un control efectivo.