¿Por qué nos obsesionamos con el verde?
Os voy a ser sincero: hubo una época en la que no podía dormir si mi informe de coverage bajaba del 99.8%. Me sentía como un impostor si alguna línea de código, por irrelevante que fuera, no estaba cubierta por un test unitario. Para mí, ese número era una medalla de honor, una prueba irrefutable de que mi código era 'de calidad'. Pero con los años, y después de darme bastantes cabezazos contra el teclado, me he dado cuenta de que esa obsesión es, en muchos casos, un error de bulto que nos aleja de lo que realmente importa: entregar valor.
Mi experiencia con la trampa del 100%
Recuerdo perfectamente un proyecto en el que trabajé hace unos años. Era una aplicación de gestión financiera bastante compleja. Nos pusimos la medalla de los puristas y decidimos que nada entraría a producción si no tenía un coverage total. Al principio, todo eran risas y palmaditas en la espalda. Ver esos informes de Jest o Estambul en un verde reluciente te da un subidón de dopamina increíble. Te sientes seguro, piensas que nada puede fallar.
Sin embargo, la realidad nos dio un bofetón de los buenos un par de meses después. Teníamos que hacer un cambio en la lógica de cálculo de impuestos. Era una modificación pequeña en el código real, quizás diez líneas. Pero, ¿sabéis qué pasó? Tuvimos que dedicar tres días enteros a actualizar los tests. Habíamos testeado hasta el último detalle de la implementación interna, funciones privadas, constantes... todo. Los tests eran tan rígidos que cualquier cambio, por mínimo que fuera, los rompía todos. Ahí fue cuando me pregunté: ¿estamos testeando para asegurar el comportamiento o estamos testeando por el simple placer de ver el número 100?
El coste oculto de la perfección numérica
Lo que nadie te cuenta cuando empiezas en esto es que el último 10% o 15% de coverage es el más caro de conseguir y el que menos valor aporta. Testear que un componente de UI renderiza un texto estático, o que un 'getter' devuelve lo que tiene que devolver, suele ser una pérdida de tiempo monumental. Son tests que no detectan errores reales, solo te dicen que has escrito el código que acabas de escribir. Es redundancia pura.
Además, está el tema del mantenimiento. Un suite de tests con cobertura total suele ser frágil. Si te enfocas en cubrir líneas y no en cubrir comportamientos, acabas con un código acoplado a tus tests. Me he visto a mí mismo borrando tests útiles porque me daba pereza actualizarlos tras un refactor, simplemente porque estaban mal enfocados desde el principio. Eso es lo contrario a lo que buscamos con el testing, que debería ser nuestra red de seguridad para refactorizar con confianza.
Lo que he aprendido: Calidad sobre cantidad
Hoy en día, mi enfoque ha cambiado radicalmente. Ya no miro el porcentaje global como si fuera el oráculo de la verdad. Prefiero tener un 70% de cobertura que cubra los flujos críticos de la aplicación (el 'happy path' y los casos de error más probables) que un 100% que incluya hasta el último 'else' de un log de consola.
He aprendido a priorizar los tests de integración. Me dan mucha más tranquilidad. Saber que el frontend habla bien con el backend y que el usuario puede completar un proceso de compra de principio a fin vale mucho más que mil tests unitarios de funciones aisladas. Si mi lógica de negocio está bien protegida y los flujos principales funcionan, duermo a pierna suelta, aunque el informe me diga que tengo un 82% de coverage.
// Un ejemplo de lo que YA NO hago: testear obviedades
it('should return the correct name', () => {
const user = new User('Roberto');
expect(user.getName()).toBe('Roberto');
});
// Lo que SÍ hago: testear lógica que realmente puede fallar
it('should correctly calculate the discount based on user loyalty years', () => {
const discount = calculateDiscount(userWithFiveYears);
expect(discount).toBe(0.15);
});Reflexiones finales
No me malinterpretéis, no estoy diciendo que no haya que testear. El testing es fundamental. Pero debemos ser pragmáticos. Nuestro tiempo como desarrolladores es limitado y muy caro. Invertir horas en conseguir ese 100% de coverage en código trivial es, a menudo, un desperdicio de recursos de la empresa y una fuente de frustración personal. Al final del día, lo que importa es que el software funcione, sea mantenible y resuelva problemas reales.
Si estás empezando, mi consejo es: no te obsesiones con el número. Pregúntate siempre: 'Si cambio este código mañana, ¿este test me ayudará a no romper nada o será solo un estorbo?'. Esa es la verdadera métrica de éxito. La paz mental no viene de un informe de cobertura perfecto, sino de saber que tus tests protegen lo que de verdad importa a tus usuarios.