“Los tests de integración cuestan 3 veces más en tiempo de escritura que los unit tests pero detectan 5 veces más bugs de producción reales. Un bug de autenticación en producción puede costar 20 horas de mitigación; el mismo bug en testing cuesta menos de 1 hora. El 45% del código generado por IA contiene vulnerabilidades según estudios de 2025 — exactamente donde los tests críticos hacen la diferencia.
A veces lanzo sin tests porque los tests en SaaS no son un checkbox de calidad: son una decisión sobre riesgo, cobertura y velocidad. Omitirlos puede ser deliberado y correcto, o descuido. La diferencia está en si lo pensaste antes de lanzar o después de que algo se rompió.
Opero varios SaaS con un equipo pequeño apoyado en agentes. Si tuviera que testear todo antes de cada deploy, el costo de mantenimiento de los tests superaría el costo de los bugs que previenen. Eso no es una opinión: es una consecuencia aritmética del tamaño del equipo y la velocidad de iteración. Pero tampoco significa testear nada: significa tener criterios explícitos.
Los tests de integración cuestan en promedio 3 veces más en tiempo de escritura que los unit tests, pero detectan 5 veces más bugs de producción reales. Un bug de autenticación en producción puede costar 20 horas de mitigación; el mismo bug detectado en testing cuesta menos de 1 hora. La decisión de no testear debe ser explícita: hay situaciones donde es válida, y otras donde es una apuesta que no conviene tomar.
Por qué "siempre testear todo" no escala en un SaaS de nicho
Tres categorías donde nunca omito tests, sin importar la etapa:
- Autenticación y autorización: una fuga de tenant o bypass de permisos es catastrófico.
- Lógica de billing y pagos: un cargo doble o suscripción incorrecta tiene costo directo en USD.
- Migraciones de base de datos: los datos de producción no son reversibles con git revert.
El argumento para testear todo parte de un supuesto razonable: los bugs son caros. Pero no tiene en cuenta que los tests también tienen costo. Hay que escribirlos, mantenerlos, arreglarlos cuando el código cambia, y distinguir entre tests que protegen algo real y tests que solo dan la ilusión de cobertura.
En un SaaS de nicho, la mayoría de los bugs no vienen de código complejo: vienen de entender mal el problema de negocio. Y para eso, un test no ayuda. El test valida que el código hace lo que cree que debe hacer — no que estás construyendo lo correcto.
Eso no es un argumento contra los tests. Es un argumento contra la cobertura de cobertura: el hábito de agregar tests para que el número suba, no para proteger algo que puede romperse de manera costosa.
Cuándo omito tests en SaaS deliberadamente
| Tipo de código | ¿Tests obligatorios? | Por qué |
|---|---|---|
| MVP pre-validación | No necesariamente | El código puede tirarse si la idea no valida |
| Reglas de autenticación | Siempre | Un bug es una brecha de seguridad |
| Lógica de billing y pagos | Siempre | Un error cuesta dinero real a clientes |
| Scripts de migración de datos | Siempre | Los datos de producción son irreversibles |
| Componentes visuales sin lógica | Opcional | Bajo riesgo, cambio frecuente |
Tengo criterios explícitos. Omito tests cuando:
- El módulo es nuevo y todavía estoy aprendiendo qué debería hacer. Los tests prematuros fijan la interface antes de entenderla y obligan a reescribirlos cuando el diseño cambia.
- El cambio es reversible y el fallo es visible inmediatamente (una pantalla que no carga, un mensaje que no aparece). Si el error es visible antes que el usuario llegue a reportarlo, el costo del fallo es bajo.
- El agente cubre la revisión: si Claude puede inspeccionar el diff y validar que la lógica es correcta, eso sustituye al test en cambios de bajo riesgo.
- El módulo no toca datos, pagos, permisos ni flujos críticos de negocio.
- El componente es UI pura sin lógica de negocio. Los tests de snapshot de componentes React tienen un costo de mantenimiento alto y un valor de protección bajo.
Esto es consistente con la filosofía de arquitectura SaaS convencional vs innovadora: la energía técnica tiene que ir donde genera valor. Testear código que no puede fallar de manera costosa no genera valor.
Qué nunca lanzo sin tests en SaaS
La lista corta de lo que siempre tiene cobertura:
Auth y sesiones. Un bug aquí puede exponer datos de otro tenant o bloquear a todos los usuarios. El costo del fallo es catastrófico y silencioso: el usuario no sabe que está viendo datos incorrectos, o no puede acceder, y el daño se multiplica.
Pagos y facturación. Si algo falla en el flujo de cobro, pierdo dinero o el usuario pierde acceso. Ambos escenarios son caros en dinero, en soporte y en confianza.
Migración de datos. Si el script de migración tiene un bug, los datos quedan corruptos. No hay rollback simple. Antes de cada migración que modifica datos existentes, tengo un test que valida la transformación sobre una muestra representativa.
Contratos de API entre servicios. Si cambio la interface y no lo detecto, el bug aparece en producción sin aviso. Los tests de contrato son especialmente importantes en arquitecturas multi-SaaS donde varios productos consumen el mismo paquete.
El resto es criterio por módulo. No hay una respuesta universal: hay una pregunta que repetir para cada caso.
Cómo decido si un módulo necesita tests en SaaS
Pregunto cinco cosas:
¿Si esto falla silenciosamente, lo sé antes que el usuario? Si la respuesta es no, necesito cobertura.
¿El fallo es reversible? Un error en una operación de lectura es más barato que un error en una escritura. Si hay escritura, el umbral para testear baja.
¿Hay datos, pagos o seguridad involucrados? Si cualquiera de los tres está presente, testeo sin importar el tamaño del módulo.
¿Este código va a ser consumido por otros módulos o servicios? Si sí, el contrato de interface necesita protección.
¿El costo de mantener el test va a superar el costo esperado del bug? En módulos muy volátiles durante el diseño inicial, la respuesta suele ser sí. Espero a que el diseño se estabilice.
El rol de los agentes en la cobertura
En 2025 los agentes cambiaron mi modelo de cobertura. Uso Claude para revisar diffs antes de deploy, validar que la lógica es consistente con el contexto del módulo y detectar regresiones obvias. Eso no reemplaza tests de contrato en código crítico, pero sí reduce el riesgo en cambios de bajo impacto.
La consecuencia es que puedo mover más rápido en partes del sistema donde antes habría esperado tener cobertura completa. No porque el riesgo desapareció, sino porque la cobertura se trasladó a una capa diferente.
Lo que los agentes no reemplazan: los tests de contrato en interfaces entre servicios, los tests de integración en flujos de pago, y los tests de regresión en auth. Esos necesitan ser automáticos, reproducibles y no depender de que alguien recuerde ejecutarlos.
Esto se conecta con el principio de código mantenible que no pide atención: la cobertura real no es la cantidad de tests, sino cuán bien entendés el sistema y dónde pueden fallar las cosas que importan.
Si estás construyendo un SaaS y necesitás ayuda para definir una estrategia de testing que no sea un obstáculo sino una ventaja, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Cuándo es válido lanzar un SaaS sin tests? Cuando el riesgo está acotado, el módulo es reversible, no compromete datos, pagos ni seguridad, y el costo de testear supera el costo esperado del fallo. No es una regla permanente: es una decisión por módulo.
¿Qué partes de un SaaS nunca deberían lanzarse sin tests? Auth, pagos, migración de datos y cualquier flujo que, si falla silenciosamente, produce daño real al usuario o al negocio.
¿Los agentes reemplazan los tests en un SaaS? Parcialmente. Los agentes pueden correr revisiones y validar cambios. Pero no reemplazan tests de contrato en código crítico: son una capa adicional, no un sustituto.
¿Cómo decido si un módulo necesita tests? Pregunto: ¿si esto falla silenciosamente, lo sé antes que el usuario? ¿El fallo es reversible? ¿Hay datos, pagos o seguridad involucrados? Si la respuesta a cualquiera es problemática, testeo.