El proyecto sin tests es más común de lo que crees

Si tu aplicación no tiene ni un solo test automatizado, no estás solo. Es la situación más habitual que nos encontramos al auditar proyectos: código que funciona (más o menos), desplegado en producción, mantenido por un equipo que tiene miedo de tocar nada porque «la última vez que cambiamos esto se rompió otra cosa».

La buena noticia es que no hace falta detener el desarrollo durante seis meses para «ponerse al día con los tests». Ese enfoque, además de inviable comercialmente, suele fracasar: se escriben miles de tests de poco valor que nadie mantendrá. Hay una forma mucho más pragmática de empezar, y es la que aplicamos cuando aterrizamos en un proyecto sin cobertura.

Primero: entiende para qué sirven (y para qué no)

Un test automatizado no es un fin en sí mismo. Es una red de seguridad que te permite cambiar código con confianza, detectar regresiones antes que tus usuarios y documentar cómo se comporta el sistema. El objetivo no es «tener tests», es poder evolucionar el software sin miedo.

También conviene saber lo que no son: los tests no garantizan que el software esté libre de errores, ni sustituyen a una buena arquitectura, ni hacen mágico un código ilegible. Son una herramienta más, pero de las que más retorno dan por euro invertido.

La pirámide de tests: dónde poner el esfuerzo

No todos los tests cuestan lo mismo ni aportan lo mismo. La pirámide clásica sigue siendo la mejor guía:

• Tests unitarios (la base): prueban una pieza pequeña de lógica de forma aislada. Son rápidos, baratos de escribir y de mantener. Aquí debe estar la mayor parte de tu cobertura.
• Tests de integración (el medio): comprueban que varias piezas funcionan juntas —un caso de uso completo contra la base de datos real, un repositorio, un adaptador de API. Menos numerosos, pero cruciales en aplicaciones de negocio.
• Tests end-to-end (la punta): simulan al usuario recorriendo la aplicación completa. Son lentos y frágiles, así que resérvalos para los dos o tres flujos críticos del negocio (registro, compra, pago). Diez buenos tests E2E valen más que doscientos que fallan aleatoriamente.

El error más común es invertir la pirámide: empezar escribiendo decenas de tests de interfaz con Selenium o Playwright que tardan una eternidad, se rompen con cada cambio de CSS y acaban desactivados. Empieza por abajo.

La estrategia que funciona: el «ratón de biblioteca»

Con un proyecto sin tests, la regla que aplicamos es sencilla: nunca escribas tests para todo el código existente de golpe. En su lugar:

1. Cada bug que se corrige, sale con un test. Antes de tocar el código defectuoso, escribe el test que reproduce el fallo. Comprueba que falla. Arréglalo. Comprueba que pasa. Así cada corrección deja una huella permanente y el mismo bug no vuelve nunca.
2. Cada funcionalidad nueva, sale con tests. No es negociable. El código nuevo es el más fácil de testear porque aún está fresco en la cabeza de quien lo escribe.
3. Cuando toques código legacy, testea solo lo que vas a cambiar. Si vas a modificar una función, primero escribe tests que capturen su comportamiento actual (los llamados characterization tests). Aunque el comportamiento sea raro, te dan la seguridad de que tu cambio no altera lo que no debe alterar.

Con estas tres reglas, la cobertura crece sola y —lo más importante— crece exactamente donde duele: en el código que se modifica con frecuencia. El código que nadie toca desde hace dos años no necesita tests urgentes.

Por dónde empezar la primera semana

Un plan realista para un equipo que arranca de cero:

1. Elige una sola herramienta y configúrala en CI: PHPUnit, Jest, pytest… la que encaje con tu stack. Que correr los tests sea un comando, no un ritual.
2. Escribe el primer test sobre la regla de negocio más valiosa y más pura que tengas: ese cálculo de precios, esa validación de pedidos. Lógica sin base de datos ni HTTP. El primer test debe ser una victoria fácil.
3. Haz que el pipeline falle si los tests fallan. Un test que se puede ignorar es un test muerto.
4. Mide la cobertura, pero no la conviertas en dogma. Pasar de 0 % a 30 % en las zonas críticas cambia la vida del equipo. Obsesionarse con el 90 % genera tests inútiles que inflan la cifra.

Los errores que hay que evitar desde el día uno

• Testear la implementación en lugar del comportamiento. Si el test se rompe cada vez que refactorizas sin cambiar funcionalidad, está acoplado a los detalles internos.
• Moches por todas partes. Un test donde todo es un mock no prueba nada: prueba que los mocks están bien configurados.
• Tests que dependen del orden o del estado compartido. Cada test debe poder ejecutarse solo, en cualquier orden, y dar el mismo resultado.
• Convertir los tests en un impuesto. Si escribir un test cuesta más que la funcionalidad, algo va mal en el diseño del código — y los tests te lo están diciendo. Escúchalos.

¿Tu equipo no consigue arrancar?

Introducir testing en un proyecto legacy es más una cuestión de método y de hábitos que de herramientas. Si tu equipo lleva meses queriendo empezar y nunca encuentra el momento, podemos ayudarte: trabajamos codo a codo con el equipo, configuramos la base, escribimos los primeros tests juntos y dejamos el hábito instalado. Hablemos de tu proyecto.