Testing: qué merece la pena testear

El dogma del 100% coverage

Hay equipos obsesionados con métricas de cobertura. Cada línea debe estar testeada, cada branch cubierta. El número mágico es 100%.

Pero cobertura no es lo mismo que confianza. Puedes tener 100% de cobertura y tests que no validan nada útil. Puedes tener 40% de cobertura y tests que atrapan los bugs que importan.

Qué vale la pena testear

Lógica de negocio central. El código que calcula precios, aplica descuentos, valida reglas de negocio. Errores aquí tienen consecuencias serias.

Integraciones con externos. La capa que habla con APIs de terceros, bases de datos, servicios externos. Donde las cosas pueden fallar por razones fuera de tu control.

Edge cases documentados. Esos casos raros que alguien descubrió, arregló, y que volverán a pasar si no hay un test que los proteja.

Qué probablemente no vale la pena

Getters y setters triviales. Si el código no puede fallar, no necesita test.

Código de UI que cambia constantemente. Un test que valida que el botón tiene texto "Enviar" se rompe cada vez que alguien cambia el copy. Coste alto, valor bajo.

Código que es wrapper directo de librerías. Si solo llamas a una función de lodash, estás testeando lodash, no tu código.

Tests como documentación

Los mejores tests explican qué hace el código y por qué. Un buen nombre de test es documentación ejecutable.

test('applies 10% discount when cart exceeds 100 euros') cuenta una historia. test('discount function') no cuenta nada.

El verdadero valor de TDD

Test-driven development no es escribir tests primero por dogma. Es usar tests para pensar en el diseño.

Escribir el test primero te fuerza a pensar cómo se usará el código. Si el test es difícil de escribir, el código será difícil de usar.

Tests lentos matan la práctica

Una suite de tests que tarda minutos en correr no se ejecuta frecuentemente. Tests que no se ejecutan no aportan valor.

Prioriza tests rápidos que corren en segundos. Los tests de integración lentos van en un pipeline separado.

Mantenimiento de tests

Los tests son código. Código que hay que mantener. Tests frágiles que se rompen con cada cambio interno generan trabajo sin aportar protección.

Testa comportamiento, no implementación. Si cambiar cómo está organizado el código rompe tests sin cambiar qué hace, los tests están mal diseñados.

El equilibrio práctico

No hay número mágico de tests ni porcentaje de cobertura correcto. Hay preguntas que hacerse.

¿Tengo confianza para hacer cambios sin miedo? ¿Los tests atrapan errores antes de producción? ¿El tiempo que invierto en tests se recupera en tiempo no gastado depurando?

Si la respuesta es sí, tienes suficientes tests. Si es no, necesitas más tests en los lugares correctos, no más tests en cualquier lugar.