De 12% a 55% de cobertura de tests sin romper la suite
Cobertura de tests al 12% es un impuesto a cada cambio. Llegar a 55% en una suite de 2,830 tests significó arreglar el entorno antes de escribir tests.
Cobertura de tests al 12% es un impuesto a cada cambio. Llegar a 55% en una suite de 2,830 tests significó arreglar el entorno antes de escribir un solo test.
Arreglá la base primero
La suite fallaba con errores de "React duplicate instance" en los stores — un problema conocido de pnpm. Agregar resolve.dedupe para react y react-dom limpió 169 fallos de una. Sin eso, ningún cantidad de escritura de tests importaba.
Capas desde el contrato hacia arriba
La fase uno apuntó a rutas del servidor y autenticación con tests enfocados en seguridad. La fase dos cubrió el paquete compartido: contratos tipados, IDs branded, sanitización de output. La fase tres manejó hooks del frontend. La fase cuatro tocó solo componentes de ruta crítica — login, 2FA, los forms del pipeline de trabajo.
Cada fase tenía su propio gate. Los tests del paquete compartido incluso assertean que mezclar un site ID con un job ID falle al compilar.
Scaffolding compartido lo hizo repetible
Dos habilitadores hicieron el trabajo pesado: auth compartida y mocks de logger para que cada archivo de test usara un patrón de setup, y aislamiento de claves de Redis con prefijos de scope de ejecución para que las suites no contaminaran el estado de las demás.
El resultado: 2,830 tests, cero fallos, typecheck estricto limpio. La restricción que mantuve: la lógica de actualización optimista quedó sin testear en vez de forzar un mock frágil. Ver la construcción de V5 Hub.