Testcontainers - des tests unitaires avec de vraies dépendances

• Framework open source qui fournit des bases de données, des brokers de messages, des navigateurs web, etc. pouvant s’exécuter dans des conteneurs Docker
• Aucune configuration d’environnement complexe ni objet simulé (mock) n’est nécessaire ; les dépendances de test sont définies dans le code, puis les conteneurs sont créés et supprimés à l’exécution des tests
• Prend en charge de nombreux langages et frameworks de test, et il suffit d’avoir Docker pour démarrer
• Modules : tester tout ce qui peut être conteneurisé
  • Plus de 50 modules permettent de tester divers composants comme des bases de données, des brokers de messages, etc.
• Langages pris en charge : il existe des implémentations de Testcontainers pour de nombreux langages populaires, notamment Java, Go, .NET, Node.js, Python, Rust, Haskell, Ruby, Clojure et Elixir.

Cas d’usage : comment Testcontainers peut aider

• Tests d’intégration de la couche d’accès aux données : tester le code de la couche d’accès aux données à l’aide d’instances de base de données conteneurisées
• Tests UI / d’acceptation : exécuter des tests UI automatisés avec des navigateurs web conteneurisés compatibles avec Selenium
• Tests d’intégration applicative : exécuter l’application dans un mode de test éphémère avec des dépendances telles qu’une base de données, une file de messages ou un serveur web, afin d’offrir un environnement riche pour les interactions et les tests exploratoires

L’avis de GN⁺

• Testcontainers permet aux développeurs d’effectuer des tests dans des conditions proches de l’environnement réel, ce qui contribue à améliorer la qualité logicielle.
• Les tests avec de vraies dépendances peuvent fournir des résultats plus précis que ceux basés sur des objets simulés, mais dans les systèmes complexes, la configuration et la gestion peuvent devenir difficiles.
• Parmi les autres projets offrant des fonctionnalités similaires à Testcontainers, on peut citer Docker Compose et Kubernetes Minikube, qui peuvent également être utilisés comme outils d’aide aux tests dans les environnements de développement.
• L’adoption de Testcontainers nécessite une certaine compréhension de Docker, ainsi que des connaissances techniques sur la gestion des conteneurs et la configuration réseau.
• Les avantages de ce choix incluent la cohérence entre les environnements de développement et de test ainsi qu’une meilleure fiabilité des tests ; en contrepartie, la dépendance à l’environnement Docker et la complexité associée peuvent constituer des inconvénients.

[GN⁺]

Commentaires Hacker News

• Résumé du premier commentaire :

  • L’enthousiasme pour Testcontainers était inattendu.
  • Cela peut sembler séduisant quand on vient d’un environnement qui n’utilisait pas Docker.
  • C’est utile dans de nombreux cas d’usage, mais il est difficile de le faire bien fonctionner avec d’autres workflows conteneurisés.
  • Testcontainers est une bibliothèque dont une fonction centrale repose sur des appels shell personnalisés à la CLI Docker, ce qui entraîne des problèmes et de la complexité lorsqu’on introduit d’autres workflows conteneurisés.
  • Il a tendance à supposer qu’il ne s’exécute que sur la machine hôte et qu’il n’y a pas d’autres tâches liées à Docker, ce qui le rend souvent aussi mauvais, voire pire, que des bibliothèques non Docker.

• Résumé du deuxième commentaire :

  • Testcontainers change la donne pour les tests d’intégration.
  • Il fournit des API Docker selon le langage, permettant de lancer facilement des conteneurs et de vérifier qu’ils sont prêts à accepter des connexions.
  • Il est utilisé dans tous les nouveaux projets pour les tests d’intégration.
  • La configuration CI inclut le linting, le build, les tests unitaires, puis les tests d’intégration avec Testcontainers.
  • Les bindings par langage offrent des fonctions utilitaires pratiques pour le travail avec les bases de données.

• Résumé du troisième commentaire :

  • Il n’est pas clair en quoi cela serait préférable à l’utilisation d’un docker-compose.yml.
  • Testcontainers est relativement faible lorsqu’il existe des dépendances complexes entre les conteneurs nécessaires.
  • Une expérience d’utilisation remonte à environ 5 ans, mais la situation a peut-être beaucoup progressé depuis.

• Résumé du quatrième commentaire :

  • Les tests d’intégration utilisant de vraies bases de données / Elasticsearch / Redis / Varnish sont jugés très précieux.
  • Testcontainers se charge de tâches comme créer un nouvel index Elasticsearch pendant la suite de tests puis l’arrêter.
  • Une stratégie est préférée : couvrir autant que possible les fonctionnalités de l’application avec des tests d’intégration de style end-to-end.
  • Les tests unitaires ne sont utilisés que pour les parties du code ayant des paires entrée/sortie claires, et les mocks pour les appels à des API externes impossibles à contrôler.

• Résumé du cinquième commentaire :

  • Il y a environ 7 ans, l’auteur a écrit conex, un Testcontainers pour le langage Go.
  • Il offre une intégration de premier ordre avec le framework de test officiel de Go.

• Résumé du sixième commentaire :

  • Certains estiment qu’il est lent de fournir une nouvelle instance de navigateur propre pour chaque test.
  • Si l’on a déjà investi dans l’univers des conteneurs, accepter quelques conteneurs supplémentaires est une bonne idée.
  • Sinon, il y a peu d’avantages par rapport à la complexité ou à la lourdeur supplémentaires.

• Résumé du septième commentaire :

  • Après avoir examiné Testcontainers, l’auteur a créé sa propre version.
  • Docker est une abstraction avec beaucoup de fuites, et les tests doivent tourner dans des environnements variés.
  • Le réseau est totalement différent sur Mac, dans une VM Linux, ou dans un conteneur Docker tournant dans une VM Linux avec le socket Docker monté.
  • L’objectif est d’exécuter les tests en parallèle et d’afficher les logs correspondant à chaque test.
  • Il n’est pas certain que Testcontainers ait résolu ces problèmes, mais il est clair que le diable est dans les détails.

• Résumé du huitième commentaire :

  • L’environnement de test local est créé avec docker-compose.
  • Testcontainers semble être une abstraction dans un langage de programmation permettant de définir un environnement Docker sans apprendre la syntaxe de Docker Compose.
  • Il faut malgré tout comprendre le réseau Docker, les dépendances et les health checks pour savoir si l’environnement de test est prêt à l’emploi.

• Résumé du neuvième commentaire :

  • Pas besoin de mocks ni de configuration d’environnement complexe.
  • Les dépendances de test sont définies dans le code, puis l’exécution des tests crée et supprime les conteneurs.
  • Penser que pouvoir exécuter des tests d’intégration dans des conteneurs rend les tests unitaires inutiles est une confusion.
  • Configurer des conteneurs Docker est simple, mais les démarrer est pénible et lent.

• Résumé du dixième commentaire :

  • Il s’agit d’une question sur l’utilisation de Duke comme logo de Java.