Aseptic vs Testcontainers
Esta comparación es distinta de las demás del racimo, y conviene decirlo de entrada: Testcontainers y Aseptic no compiten. Aparecen juntos porque quien ya resolvió sus tests de integración con Testcontainers suele dar por hecho que eso le resuelve también el entorno de trabajo, y no es así. Son dos momentos distintos del día.
En una frase
Testcontainers es una librería que arranca contenedores desde el código de tus tests: pides un Postgres, te da uno de verdad, y cuando el test termina desaparece. El ciclo de vida lo gobierna el test.
Aseptic es una aplicación de escritorio que levanta un escenario de servicios y lo deja en marcha mientras trabajas, resolviendo cada dependencia a un servicio local, a tu entorno en la nube o a un mock. El ciclo de vida lo gobiernas tú.
La tabla
| Testcontainers | Aseptic | |
|---|---|---|
| Cuándo se usa | Al ejecutar un test | Mientras escribes código |
| Quién manda en el ciclo de vida | El test: nace y muere con él | Tú: levantas y se queda |
| Dónde se declara | En el código del test, con su API | En un escenario, fuera de los repos |
| Levanta TUS servicios | No — dependencias, no tu aplicación | Sí, es el objetivo |
| A dónde llama cada servicio | Lo cableas en el test | Por dependencia: local, nube o mock |
| Probar a mano un endpoint | No es su caso de uso | Sí |
| Funciona en CI | Sí, es donde más brilla | No — es de escritorio |
| Depurador en tu servicio | El de tu test | El proceso es local: como siempre |
| Licencia | Código abierto | Gratis para uso personal, de pago para uso comercial |
Quédate con Testcontainers si…
- Lo que quieres es que tus tests de integración corran contra un Postgres, un Kafka o un Redis de verdad en vez de contra un doble. Es exactamente su problema y lo resuelve mejor que nadie.
- Necesitas que eso funcione igual en CI que en tu máquina, sin instalar nada previo.
- Quieres aislamiento total entre ejecuciones: cada test con su base limpia, sin residuos de la anterior.
Quédate con Aseptic si…
- Lo que te frena no es un test rojo, sino que para probar el flujo a mano tienes que levantar cuatro servicios y no está claro en qué orden ni con qué variables.
- Quieres pegarle a un endpoint, mirar el log del servicio de al lado y reiniciarlo sin salir del sitio.
- Necesitas mezclar: dos servicios en local, uno contra el entorno de la nube y otro mockeado porque hoy no hay VPN.
- Quieres que el entorno se comparta como un fichero, para que quien entra nuevo clone, importe y arranque.
Dónde se queda corto Aseptic
No es una herramienta de tests y no corre en CI. Si intentas usarlo para lo que hace Testcontainers vas a echar de menos lo esencial: aislamiento por ejecución, arranque y parada gobernados por el propio test, y una API desde el código. Nada de eso está, ni se pretende.
Testcontainers es además código abierto, con años de rodaje y librerías en todos los lenguajes. Aseptic está en beta pública, es de escritorio y para uso comercial se paga.
Lo que suele acabar pasando
Que se usan los dos, y la costura es limpia porque cada uno vive en un momento distinto: Aseptic mientras escribes —el escenario levantado, el flujo probado a mano, el depurador enganchado— y Testcontainers cuando ejecutas la suite, en tu máquina y en CI.
El error que se ve más a menudo es intentar que uno haga el trabajo del otro: levantar el sistema entero con Testcontainers para poder «probar a mano» acaba en un test que en realidad es un arrancador, lento y difícil de mantener; y esperar que un entorno de trabajo dé el aislamiento de un test lleva a suites que fallan según lo que hiciera el anterior.
Si lo que estás comparando de verdad es cómo montar el entorno local, el punto de partida es cómo levantar un entorno de microservicios en local, y luego la comparación con Docker Compose y la página de alternativas.
Preguntas frecuentes
¿Aseptic sustituye a Testcontainers?
No, y no debería. Testcontainers vive dentro de tus tests: el contenedor nace cuando arranca el test y muere cuando acaba. Aseptic es el sitio donde trabajas mientras escribes el código, con los servicios levantados y estables. Lo normal es usar los dos, cada uno en su momento.
Si ya tengo Testcontainers, ¿qué me falta?
Un sitio donde probar a mano. Testcontainers resuelve las dependencias de un test, no dónde ejecutas el flujo cuando quieres pegarle a un endpoint, mirar un log o enganchar el depurador. Ese hueco es el que nadie cubre y por el que acaba apareciendo un LOCAL_SETUP.md de cuarenta pasos.
¿Puede Aseptic levantar dependencias para mis tests?
No es para lo que está. Un test de integración quiere un entorno que nazca y muera con él, aislado y reproducible en CI; eso es exactamente Testcontainers. Aseptic es una herramienta de escritorio y no corre en CI.
¿Los dos usan Docker?
Sí, y para cosas parecidas: contenedores de infraestructura. La diferencia es el ciclo de vida. En Testcontainers lo gobierna el test; en Aseptic, tú: los levantas cuando empiezas y siguen ahí mientras trabajas.
¿Y si mi problema es que el servicio de al lado no está levantado?
Ese es un problema de entorno de trabajo, no de tests. En Aseptic decides por dependencia si esa llamada va al servicio local, a tu entorno en la nube o a un mock, y se aplica al arrancar sin tocar el repositorio del que llama.