Aseptic vs Testcontainers
Questo confronto è diverso dagli altri del gruppo, e vale la pena dirlo subito: Testcontainers e Aseptic non competono. Compaiono insieme perché chi ha già risolto i test di integrazione con Testcontainers tende a dare per scontato che questo gli risolva anche l'ambiente di lavoro, e non è così. Sono due momenti diversi della giornata.
In una frase
Testcontainers è una libreria che avvia container dal tuo codice di test: chiedi un Postgres, ne ottieni uno vero, e quando il test finisce sparisce. È il test a governare il ciclo di vita.
Aseptic è un'applicazione desktop che avvia uno scenario di servizi e lo lascia in esecuzione mentre lavori, risolvendo ogni dipendenza verso un servizio locale, il tuo ambiente nel cloud o un mock. Sei tu a governare il ciclo di vita.
La tabella
| Testcontainers | Aseptic | |
|---|---|---|
| Quando lo usi | Nell'eseguire un test | Mentre scrivi codice |
| Di chi è il ciclo di vita | Del test: nasce e se ne va con lui | Tuo: lo avvii e resta |
| Dove si dichiara | Nel codice del test, tramite la sua API | In uno scenario, fuori dai repo |
| Esegue I TUOI servizi | No — dipendenze, non la tua applicazione | Sì, è il punto |
| Dove punta ogni servizio | Lo cabli tu nel test | Per dipendenza: locale, cloud o mock |
| Chiamare un endpoint a mano | Non è il suo caso d'uso | Sì |
| Funziona in CI | Sì, è dove brilla di più | No — è software desktop |
| Debugger sul tuo servizio | Quello del tuo test | Il processo è locale: come sempre |
| Licenza | Open source | Gratis per uso personale, a pagamento per uso commerciale |
Scegli Testcontainers se…
- Quello che vuoi sono i tuoi test di integrazione in esecuzione contro un Postgres, Kafka o Redis veri invece che contro un doppio. È precisamente il suo problema e lo risolve meglio di qualsiasi altra cosa.
- Ti serve che funzioni allo stesso modo in CI e sulla tua macchina, senza nulla installato in anticipo.
- Vuoi isolamento totale fra le esecuzioni: ogni test con un database pulito, senza resti del precedente.
Scegli Aseptic se…
- Quello che ti blocca non è un test rosso, ma il fatto che provare il flusso a mano significa avviare quattro servizi e non è chiaro in che ordine né con quali variabili.
- Vuoi chiamare un endpoint, leggere il log del servizio accanto e riavviarlo senza muoverti da lì.
- Devi mescolare: due servizi in locale, uno contro l'ambiente cloud e uno mockato perché oggi la VPN è giù.
- Vuoi l'ambiente condiviso come un file, così chi arriva clona, importa e avvia.
Dove Aseptic resta corto
Non è uno strumento di test e non gira in CI. Se provi a usarlo per quello che fa Testcontainers ti mancherà l'essenziale: isolamento per esecuzione, avvio e arresto governati dal test stesso, e un'API dal codice. Niente di tutto ciò c'è, e niente di tutto ciò è previsto.
Testcontainers è inoltre open source, con anni di chilometraggio e librerie in ogni linguaggio. Aseptic è in beta pubblica, è software desktop, e l'uso commerciale è a pagamento.
Quello che di solito finisce per succedere
Si usano entrambi, e la cucitura è pulita perché ciascuno vive in un momento diverso: Aseptic mentre scrivi —scenario su, flusso provato a mano, debugger agganciato— e Testcontainers quando esegui la suite, sulla tua macchina e in CI.
L'errore che si vede più spesso è far fare a uno il lavoro dell'altro: avviare l'intero sistema con Testcontainers per «provare le cose a mano» finisce in un test che in realtà è un lanciatore, lento e difficile da mantenere; e aspettarsi che un ambiente di lavoro ti dia l'isolamento di un test porta a suite che falliscono a seconda di cosa ha fatto l'esecuzione precedente.
Se quello che stai davvero confrontando è come costruire l'ambiente locale, il punto di partenza è come far girare un ambiente di microservizi in locale, e poi il confronto con Docker Compose e la pagina delle alternative.
Domande frequenti
Aseptic sostituisce Testcontainers?
No, e non dovrebbe. Testcontainers vive dentro i tuoi test: il container nasce quando il test parte e muore quando finisce. Aseptic è dove lavori mentre scrivi il codice, con i servizi su e stabili. La cosa normale è usarli entrambi, ciascuno nel suo momento.
Se ho già Testcontainers, cosa mi manca?
Un posto dove provare le cose a mano. Testcontainers risolve le dipendenze di un test, non il posto dove esegui il flusso quando vuoi chiamare un endpoint, leggere un log o agganciare il debugger. Quella lacuna è quella che nessuno copre, e la ragione per cui prima o poi compare un LOCAL_SETUP.md di quaranta passi.
Aseptic può avviare dipendenze per i miei test?
Non è per quello che serve. Un test di integrazione vuole un ambiente che nasce e muore con lui, isolato e riproducibile in CI; quello è esattamente Testcontainers. Aseptic è uno strumento desktop e non gira in CI.
Usano entrambi Docker?
Sì, e per cose simili: container di infrastruttura. La differenza è il ciclo di vita. In Testcontainers lo governa il test; in Aseptic, tu: li avvii quando cominci e restano lì mentre lavori.
E se il mio problema è che il servizio accanto non è in esecuzione?
Quello è un problema di ambiente di lavoro, non di test. In Aseptic decidi per dipendenza se quella chiamata va al servizio locale, al tuo ambiente nel cloud o a un mock, e si applica all'avvio senza toccare il repository che chiama.