Mais c’est quoi docker ?
Docker est un outil fantastique qui permet de déployer facilement un conteneur qui contient l’image de tout ce qu’il faut pour votre application.
Un conteneur est un « paquet » exécutable, autonome et léger qui inclut tout ce qui est nécessaire pour faire fonctionner un logiciel : son code, les outils et les librairies système, et tous les paramétrages nécessaires. Les conteneurs sont une abstraction au niveau de la couche applicative qui rassemble le code et ses dépendances.
Plusieurs conteneurs peuvent fonctionner sur la même machine et partager le noyau du système d’exploitation avec d’autres conteneurs, chacun fonctionnant comme des processus isolés dans l’espace utilisateur. Les conteneurs prennent moins d’espace que des VM (les images de conteneurs font typiquement quelques dizaines de Mega), et démarrent presque instantanément.
Disponibles pour les applications Linux et Windows, les logiciels « conteneurisés » fonctionnent toujours de la même manière, quel que soit l’environnement ; les conteneurs isolent les logiciels de leur environnement. Cela donne évidement des facilités importantes pour automatiser le déploiement et assurer que les environnements sont identiques (puisque l’image du conteneur est autonome).
Et le testeur dans tout cela
Et bien déjà, avoir un environnement disponible rapidement, isolé et en limitant les problèmes de conflits liés au déploiement est un avantage indéniable pour faire des tests sereinement.
Mais ce n’est pas le seul avantage que l’on peut tirer de docker en tant que testeur. On peut même déployer des outils spécifiques de tests dans des conteneurs.
Voyons deux exemples pratiques de ces outils.
« Selenium grid » dans du docker
Quand vous automatisez vos tests d’IHM web (avec des outils classiques comme Selenium, protractor, …) il n’est pas toujours facile de lancer des tests avec des « webdrivers » selenium. Il faut la bonne version du navigateur, les webdriver d’installés… sinon votre test ne va même pas démarrer. En plus, vous voulez que vos tests ne marchent pas que sur une machine, mais soient lancés lors de l’intégration continue. Enfin, vous voulez certainement faire des tests avec plusieurs navigateurs ou systèmes d’exploitation pour vérifier la portabilité de votre application.
L’utilisation de « selenium grid » peut résoudre tous ces problèmes, les « webdrivers » tournant sur des hôtes dédiés, ces hôtes peuvent être différents aussi bien en terme de système d’exploitation que de navigateurs. Mais gérer ces hôtes n’est pas une chose si facile.
Une solution est d’utiliser docker pour déployer vos hôtes Selenium. En plus il existe des solutions open source pour le faire :
- Zalenium : https://github.com/zalando/zalenium
- Selenium Docker : https://github.com/SeleniumHQ/docker-selenium
Zalenium par exemple est facile d’utilisation, il gère les conteneurs de la grille de façon autonome et peut même rediriger vos tests vers une solution de tests automatisés du cloud (Sauce Labs, BrowserStack, TestingBot) pour gérer les différents OS et les différentes versions des navigateurs (non disponibles dans les conteneurs)
Du point de vue du test, rien ne change, utiliser une grille Selenium dans un docker ne change pas l’accès au « RemoteWebDriver» en donnant l’url de la grille Selenium (http://localhost:4444/wd/hub par défaut si docker tourne en local)
L’avantage par rapport à une grille Selenium classique et la possibilité d’ajouter et de supprimer des dockers en fonction du besoin, et tout cela rapidement.
TestContainers
Une autre utilisation des conteneurs encore plus intéressante est de les utiliser pour lancer vos tests d’intégration de façon isolée (sur une vraie base de données par exemple). Ces environnements étant isolés, rapides à générer et indépendants, vous pouvez facilement lancer des tests sur la vraie base de données, ou en intégrant plusieurs micro-services.
Là encore un open source peut vous aider si vous développez en Java : TestContainers (https://www.testcontainers.org/). Vous pouvez facilement le combiner avec des outils de mocking pour simuler les systèmes externes (en utilisant l’image de conteneur de mock-server : http://www.mock-server.com/where/docker.html)
Un rappel important de la pyramide de tests : privilégiez les tests de bas niveaux. Les tests de bas niveaux n’ont pas besoin d’environnement, vous pouvez facilement tout bouchonner et simuler (en utilisant une base de données en mémoire par exemple). Mais même si vous mettez l’accent sur les tests unitaires, il faut respecter la pyramide, et donc lancer des tests face aux vrais systèmes (intégration). C’est là que docker peut vous aider sans pour autant avoir besoin d’environnement spécifique, et en simplifiant certain bouchonnages (toujours nécessaires)
Grace à TestContainers, les conteneurs peuvent être gérés depuis le code java, ce qui permet de faire aisément des tests plus intégrés lançable en intégration continue, sans avoir besoin d’un environnement dédié.
Enfin, avec TestContainers, vous pouvez même utiliser une image Selenium Docker pour lancer des tests d’IHM. Même si cela est très intéressant (et remplace complétement une grille Selenium, puisque tout est déployé dans docker), pour moi ce n’est pas la principale utilité, il est plus intéressant d’utiliser TestContainers pour faire des tests d’intégration (et respecter la pyramide de tests).
