Por qué tardamos tres años en meter tests automatizados (y qué nos hizo cambiar)

Durante los tres primeros años de la agencia no escribíamos ni un test. Cero. Hacíamos la web, la probábamos a mano un rato antes de entregarla y ya está. Funcionaba, hasta que dejaba de funcionar.

Meter tests automatizados merece la pena sobre todo en la lógica que maneja dinero o disponibilidad — precios, descuentos, reservas — no en todo el proyecto, porque ahí es donde un fallo silencioso sale caro, del mismo tipo que el parche de una dependencia que tumbó un checkout, y un test de una tarde evita que se repita. El caso que nos hizo cambiar de opinión fue un proyecto de reservas para un negocio de turismo activo (kayaks, rutas guiadas, ese tipo de cosa). Tenían un formulario de reserva con lógica de disponibilidad bastante enrevesada: fechas bloqueadas, aforo máximo por actividad, descuentos por grupo. Cada vez que tocábamos algo del calendario rompíamos otra cosa sin darnos cuenta. Y no lo veíamos nosotros: lo veía el cliente, cuando alguien conseguía reservar dos veces la misma plaza.

Pasó tres veces en un mes. La tercera el cliente nos llamó bastante mosqueado, con razón.

Ahí decidimos meter Vitest en ese proyecto, solo para la lógica de disponibilidad, sin tocar nada más. Nada de cobertura al 100% ni gestión pomposa de calidad: cogimos las cuatro funciones que calculaban plazas libres y les escribimos test de los casos que ya sabíamos que fallaban. Tardamos día y medio. Desde entonces esa lógica no se ha vuelto a romper, ni una vez, en año y medio.

Lo que nos costó entender es que no hacía falta testear todo el proyecto para que mereciera la pena. Seguimos sin tener ni un test en el 90% del código que escribimos: páginas estáticas, formularios de contacto simples, cosas que si se rompen se ven a simple vista en cinco minutos. Donde sí metemos tests ahora es en cálculos: precios con descuentos, disponibilidad, cualquier lógica que dependa de fechas o de combinaciones de condiciones que un humano no revisa bien mentalmente.

Uso un criterio sencillo para decidir. Si un bug en esa función le cuesta dinero directamente al cliente (una reserva duplicada, un precio mal calculado) o si el fallo es silencioso, no salta ningún error, simplemente el resultado es el equivocado, ahí meto test. Si el fallo es visual y obvio, no.

Tampoco es gratis, esto. Hay proyectos donde el presupuesto no da para más de 40 horas de desarrollo, y meter tests son horas que no facturas como funcionalidad visible. A un cliente nuevo le cuesta entender por qué has tardado dos días extra en algo que “no se ve”. Con clientes recurrentes, con los que ya hay confianza, se lo explico directamente: esto evita que me llames en agosto porque algo se ha roto. Con un cliente de una sola vez, la verdad, a veces ni lo menciono y ajusto el presupuesto interno sin más.

Lo que todavía no tengo resuelto es cuándo merece la pena meter tests end-to-end con Playwright en vez de solo tests de lógica. Los hemos usado en dos proyectos y en uno se volvieron tan frágiles con cada cambio de CSS que acabamos borrándolos a los cuatro meses. No sé si el problema fue cómo los escribimos o si simplemente no encajan con proyectos que cambian de diseño cada dos por tres.