La cobertura de código es un métrica valiosa cuando se usa bien. El problema es que muchos equipos la persiguen como un fin en sí misma, escribiendo tests de cosas triviales mientras dejan sin testing la lógica crítica.
Qué merece ser testeado
Testea la lógica de negocio: reglas, cálculos, decisiones. Testea el camino feliz y los errores esperados. No testees código trivial: getters, boilerplate sin lógica, código generado.
Cuando defines "qué testear" con criterio, llegas a cobertura significativa sin bloat.
- Lógica de negocio: primer candidato.
- Cambios de estado: si afecta a usuarios, testénlo.
- Integraciones críticas: externos que pueden fallar.
Jest vs Vitest: cuándo elegir cuál
Jest es la opción segura. Funciona en casi cualquier parte y es ampliamente conocido. Vitest es más rápido, integra mejor con Vite y tiene una experiencia de desarrollo mejor.
Para proyectos nuevos, Vitest es probablemente tu mejor bet. Para legacy o equipos que solo conocen Jest, Jest funciona bien.
- Proyectos nuevos: considera Vitest primero.
- Proyectos existentes: Jest sigue siendo válido.
- Lo importante no es la herramienta, es la disciplina de testing.
Estructura y organización de tests
Los tests deben vivir cerca del código que testean, ser fáciles de leer y estar organizados por tipo: unitarios cerca de módulos, integración en una carpeta separada, e2e en su propio directorio.
Nombres descriptivos importan. Un test que se llama "debe fallar" no dice nada. Uno que se llama "debe rechazar email inválido" ya comunica la expectativa.
- Tests unitarios en __tests__ o .test.ts junto al código.
- Tests de integración agrupados por feature.
- E2E en carpeta separada con setup claro.
Mocking inteligente: no mockees más de lo necesario
El mocking es una herramienta poderosa que puede convertirse en un arma. Si mockeas todo, estás testeando tus mocks, no tu código. Mockea lo que es externo: APIs, bases de datos, efectos secundarios. No mockees la lógica que quieres probar.
Un test que requiere demasiados mocks es una señal de que el código está demasiado acoplado.
Cobertura que importa
Establece un umbral mínimo de cobertura (quizá 70-80%) pero no lo persigues en cada línea. Enfócate en que el código crítico esté probado y que los cambios futuros se hagan con confianza.
La métrica correcta no es "¿cuánto código testeo?" sino "¿con qué confianza puedo desplegar cambios?".