Por que tardamos tres anos en meter tests automatizados (e que nos fixo cambiar)
Durante os tres primeiros anos da axencia non escribiamos nin un test. Cero. Faciamos a web, probabámola a man un rato antes de entregala e xa está. Funcionaba, ata que deixaba de funcionar.
Meter tests automatizados paga a pena sobre todo na lóxica que manexa diñeiro ou dispoñibilidade — prezos, descontos, reservas — non en todo o proxecto, porque aí é onde un fallo silencioso sae caro, do mesmo tipo que o parche dunha dependencia que tirou un checkout, e un test dunha tarde evita que se repita. O caso que nos fixo cambiar foi un proxecto de reservas para un negocio de turismo activo (kaiaks, rutas guiadas, ese tipo de cousa). Tiñan un formulario de reserva cunha lóxica de dispoñibilidade bastante enleada: datas bloqueadas, aforo máximo por actividade, descontos por grupo. Cada vez que tocabamos algo do calendario rompiamos outra cousa sen decatarnos. E non o viamos nós: víao o cliente, cando alguén conseguía reservar dúas veces a mesma praza.
Pasou tres veces nun mes. A terceira vez o cliente chamounos bastante anoxado, con razón.
Aí decidimos meter Vitest nese proxecto, só para a lóxica de dispoñibilidade, sen tocar máis nada. Nada de cobertura ao 100% nin xestión pomposa de calidade: collemos as catro funcións que calculaban prazas libres e escribimos tests dos casos que xa sabiamos que fallaban. Tardamos día e medio. Dende entón esa lóxica non se volveu romper, nin unha vez, en ano e medio.
O que nos custou entender é que non facía falta testear todo o proxecto para que merecese a pena. Seguimos sen ter nin un test no 90% do código que escribimos: páxinas estáticas, formularios de contacto simples, cousas que se se rompen vense a simple vista en cinco minutos. Onde si metemos tests agora é nos cálculos: prezos con descontos, dispoñibilidade, calquera lóxica que dependa de datas ou de combinacións de condicións que unha persoa non revisa ben na cabeza.
Uso un criterio sinxelo para decidir. Se un bug nesa función lle custa diñeiro directamente ao cliente (unha reserva duplicada, un prezo mal calculado) ou se o fallo é silencioso, non salta ningún erro, simplemente o resultado é o equivocado, aí meto test. Se o fallo é visual e evidente, non.
Tampouco é de balde, isto. Hai proxectos onde o orzamento non dá para máis de 40 horas de desenvolvemento, e meter tests son horas que non facturas como funcionalidade visible. A un cliente novo cústalle entender por que tardaches dous días máis nunha cousa que “non se ve”. Con clientes habituais, cos que xa hai confianza, dígollelo directamente: isto evita que me chames en agosto porque algo se rompeu. Cun cliente dunha soa vez, a verdade, ás veces nin o menciono e axusto o orzamento interno sen máis.
O que aínda non teño resolto é cando paga a pena meter tests end-to-end con Playwright en vez de só tests de lóxica. Usámolos en dous proxectos e nun volvéronse tan fráxiles con cada cambio de CSS que acabamos borrándoos aos catro meses. Non sei se o problema foi como os escribimos ou se simplemente non encaixan con proxectos que cambian de deseño cada dous por tres.