Aseptic vs Testcontainers
Este comparativo é diferente dos outros do conjunto, e vale a pena dizê-lo já: o Testcontainers e o Aseptic não competem. Aparecem juntos porque quem já resolveu os testes de integração com o Testcontainers tende a assumir que isso também lhe resolve o ambiente de trabalho, e não resolve. São dois momentos diferentes do dia.
Numa frase
O Testcontainers é uma biblioteca que arranca contentores a partir do teu código de teste: pedes um Postgres, recebes um a sério, e quando o teste acaba desaparece. O teste governa o ciclo de vida.
O Aseptic é uma aplicação de ambiente de trabalho que levanta um cenário de serviços e o deixa a correr enquanto trabalhas, resolvendo cada dependência para um serviço local, o teu ambiente na nuvem ou um mock. Tu governas o ciclo de vida.
A tabela
| Testcontainers | Aseptic | |
|---|---|---|
| Quando o usas | Ao executar um teste | Enquanto escreves código |
| De quem é o ciclo de vida | Do teste: nasce e vai-se com ele | Teu: levanta-lo e fica |
| Onde se declara | No código do teste, pela sua API | Num cenário, fora dos repos |
| Corre OS TEUS serviços | Não — dependências, não a tua aplicação | Sim, é esse o ponto |
| Para onde aponta cada serviço | Ligas tu no teste | Por dependência: local, nuvem ou mock |
| Chamar um endpoint à mão | Não é o seu caso de uso | Sim |
| Funciona na CI | Sim, é onde mais brilha | Não — é software de ambiente de trabalho |
| Depurador no teu serviço | O do teu teste | O processo é local: como sempre |
| Licença | Código aberto | Grátis para uso pessoal, pago para uso comercial |
Escolhe o Testcontainers se…
- O que queres são os teus testes de integração a correr contra um Postgres, Kafka ou Redis a sério em vez de um duplo. É esse precisamente o seu problema e resolve-o melhor do que qualquer outra coisa.
- Precisas que isso funcione igual na CI e na tua máquina, sem nada instalado de antemão.
- Queres isolamento total entre execuções: cada teste com uma base de dados limpa, sem restos do anterior.
Escolhe o Aseptic se…
- O que te bloqueia não é um teste vermelho, mas que experimentar o fluxo à mão implica levantar quatro serviços e não é claro em que ordem nem com que variáveis.
- Queres chamar um endpoint, ler o log do serviço do lado e reiniciá-lo sem sair do sítio.
- Precisas de misturar: dois serviços em local, um contra o ambiente da nuvem e um com mock porque hoje não há VPN.
- Queres o ambiente partilhado como um ficheiro, para que quem chega clone, importe e arranque.
Onde o Aseptic fica curto
Não é uma ferramenta de testes e não corre na CI. Se tentares usá-lo para o que o Testcontainers faz, vais dar pela falta do essencial: isolamento por execução, arranque e paragem governados pelo próprio teste, e uma API a partir do código. Nada disso está lá, e nada disso é intencional.
O Testcontainers é também código aberto, com anos de quilómetros e bibliotecas em todas as linguagens. O Aseptic está em beta pública, é software de ambiente de trabalho, e o uso comercial é pago.
O que costuma acabar por acontecer
Usam-se os dois, e a costura é limpa porque cada um vive num momento diferente: o Aseptic enquanto escreves —cenário de pé, fluxo experimentado à mão, depurador ligado— e o Testcontainers quando corres a suite, na tua máquina e na CI.
O erro que mais se vê é pôr um a fazer o trabalho do outro: levantar o sistema inteiro com o Testcontainers para «experimentar coisas à mão» acaba num teste que é na verdade um lançador, lento e difícil de manter; e esperar que um ambiente de trabalho te dê o isolamento de um teste leva a suites que falham consoante o que a execução anterior fez.
Se o que estás mesmo a comparar é como montar o ambiente local, o ponto de partida é como correr um ambiente de microsserviços em local, e depois a comparação com o Docker Compose e a página de alternativas.
Perguntas frequentes
O Aseptic substitui o Testcontainers?
Não, e não devia. O Testcontainers vive dentro dos teus testes: o contentor nasce quando o teste começa e morre quando acaba. O Aseptic é onde trabalhas enquanto escreves o código, com os serviços de pé e estáveis. O normal é usar os dois, cada um no seu momento.
Se já tenho o Testcontainers, o que me falta?
Um sítio onde experimentar as coisas à mão. O Testcontainers resolve as dependências de um teste, não o sítio onde corres o fluxo quando queres chamar um endpoint, ler um log ou ligar o depurador. Essa lacuna é a que ninguém cobre, e a razão pela qual acaba por aparecer um LOCAL_SETUP.md de quarenta passos.
O Aseptic pode levantar dependências para os meus testes?
Não é para isso que serve. Um teste de integração quer um ambiente que nasce e morre com ele, isolado e reproduzível na CI; isso é exatamente o Testcontainers. O Aseptic é uma ferramenta de ambiente de trabalho e não corre na CI.
Ambos usam Docker?
Sim, e para coisas parecidas: contentores de infraestrutura. A diferença é o ciclo de vida. No Testcontainers governa-o o teste; no Aseptic, tu: levanta-los quando começas e ficam ali enquanto trabalhas.
E se o meu problema é que o serviço do lado não está a correr?
Isso é um problema de ambiente de trabalho, não de testes. No Aseptic decides por dependência se essa chamada vai para o serviço local, para o teu ambiente na nuvem ou para um mock, e aplica-se ao arrancar sem tocar no repositório que chama.