Aseptic vs Testcontainers
Cette comparaison n'est pas comme les autres, et autant le dire d'emblée : Testcontainers et Aseptic ne sont pas concurrents. Ils apparaissent ensemble parce que ceux qui ont déjà réglé leurs tests d'intégration avec Testcontainers supposent volontiers que cela règle aussi leur environnement de travail, et ce n'est pas le cas. Ce sont deux moments différents de la journée.
En une phrase
Testcontainers est une bibliothèque qui démarre des conteneurs depuis le code de vos tests : vous demandez un Postgres, vous en obtenez un vrai, et quand le test se termine il disparaît. C'est le test qui gouverne le cycle de vie.
Aseptic est une application de bureau qui lève un scénario de services et le laisse tourner pendant que vous travaillez, en résolvant chaque dépendance vers un service local, votre environnement cloud ou un mock. C'est vous qui gouvernez le cycle de vie.
Le tableau
| Testcontainers | Aseptic | |
|---|---|---|
| Quand on s'en sert | En exécutant un test | Pendant qu'on écrit du code |
| Qui gouverne le cycle de vie | Le test : il naît et meurt avec lui | Vous : vous levez et ça reste |
| Où c'est déclaré | Dans le code du test, via son API | Dans un scénario, hors des dépôts |
| Exécute VOS services | Non — des dépendances, pas votre application | Oui, c'est le but |
| Où pointe chaque service | Vous le câblez dans le test | Par dépendance : local, cloud ou mock |
| Taper sur un endpoint à la main | Ce n'est pas son cas d'usage | Oui |
| Fonctionne en CI | Oui, c'est là qu'il brille le plus | Non — c'est un logiciel de bureau |
| Débogueur sur votre service | Celui de votre test | Le processus est local : comme d'habitude |
| Licence | Open source | Gratuit pour un usage personnel, payant en usage commercial |
Choisissez Testcontainers si…
- Ce que vous voulez, c'est que vos tests d'intégration tournent contre un vrai Postgres, Kafka ou Redis plutôt que contre un double. C'est précisément son problème et il le résout mieux que quiconque.
- Vous avez besoin que cela marche pareil en CI et sur votre machine, sans rien installer au préalable.
- Vous voulez une isolation totale entre exécutions : chaque test avec une base propre, sans résidus du précédent.
Choisissez Aseptic si…
- Ce qui vous freine n'est pas un test rouge, mais qu'essayer le flux à la main demande de lever quatre services sans savoir dans quel ordre ni avec quelles variables.
- Vous voulez taper sur un endpoint, lire le log du service d'à côté et le redémarrer sans quitter l'endroit.
- Vous avez besoin de mélanger : deux services en local, un contre l'environnement cloud et un mocké parce qu'aujourd'hui il n'y a pas de VPN.
- Vous voulez que l'environnement se partage comme un fichier, pour qu'un nouvel arrivant clone, importe et démarre.
Là où Aseptic est insuffisant
Ce n'est pas un outil de test et il ne tourne pas en CI. Si vous essayez de l'utiliser pour ce que fait Testcontainers, l'essentiel vous manquera : l'isolation par exécution, le démarrage et l'arrêt gouvernés par le test lui-même, et une API depuis le code. Rien de tout cela n'existe, et rien de tout cela n'est prévu.
Testcontainers est de plus open source, avec des années de kilomètres et des bibliothèques dans tous les langages. Aseptic est en bêta publique, c'est un logiciel de bureau, et l'usage commercial est payant.
Ce qui finit généralement par arriver
On se sert des deux, et la couture est nette parce que chacun vit à un moment différent : Aseptic pendant que vous écrivez —scénario levé, flux essayé à la main, débogueur attaché— et Testcontainers quand vous lancez la suite, sur votre machine et en CI.
L'erreur la plus fréquente est de faire faire à l'un le travail de l'autre : lever tout le système avec Testcontainers pour pouvoir « essayer à la main » finit en un test qui est en réalité un lanceur, lent et difficile à maintenir ; et attendre d'un environnement de travail l'isolation d'un test mène à des suites qui échouent selon ce qu'a fait l'exécution précédente.
Si ce que vous comparez vraiment, c'est comment monter l'environnement local, le point de départ est comment lever un environnement de microservices en local, puis la comparaison avec Docker Compose et la page des alternatives.
Questions fréquentes
Aseptic remplace-t-il Testcontainers ?
Non, et il ne devrait pas. Testcontainers vit dans vos tests : le conteneur naît quand le test démarre et meurt quand il finit. Aseptic est l'endroit où vous travaillez pendant que vous écrivez le code, avec les services levés et stables. Le normal est d'utiliser les deux, chacun à son moment.
Si j'ai déjà Testcontainers, que me manque-t-il ?
Un endroit où essayer à la main. Testcontainers résout les dépendances d'un test, pas l'endroit où vous exécutez le flux quand vous voulez taper sur un endpoint, lire un log ou attacher le débogueur. C'est le trou que personne ne bouche, et la raison pour laquelle un LOCAL_SETUP.md de quarante étapes finit par apparaître.
Aseptic peut-il lever des dépendances pour mes tests ?
Ce n'est pas sa fonction. Un test d'intégration veut un environnement qui naît et meurt avec lui, isolé et reproductible en CI ; c'est exactement Testcontainers. Aseptic est un outil de bureau et ne tourne pas en CI.
Les deux utilisent-ils Docker ?
Oui, et pour des choses proches : des conteneurs d'infrastructure. La différence est le cycle de vie. Dans Testcontainers c'est le test qui le gouverne ; dans Aseptic, c'est vous : vous les levez en commençant et ils restent pendant que vous travaillez.
Et si mon problème est que le service d'à côté n'est pas levé ?
C'est un problème d'environnement de travail, pas de tests. Dans Aseptic vous décidez par dépendance si cet appel va vers le service local, vers votre environnement cloud ou vers un mock, et c'est appliqué au démarrage sans toucher au dépôt appelant.