Industrialisation des tests, un article rédigé par Fabien OGER, Développeur Web, SYNALTIC.
Industrialisation des tests
Notre stratégie de tests
Chez Synaltic, nous avons au fil des années mis en place des processus de validation plus généralement connu sous le nom de CI/CD. De manière à ce que le code fourni réponde tant aux différentes exigences du client en matière de fonctionnalités ou dans le traitement des bugs, qu’au niveau de la manière dont le code est écrit.
Pour chaque ticket traité par les développeurs, il existe une branche git. Nous poussons cette branche dans notre Gitlab et pour chaque “push” nous définissons un pipeline.
Le pipeline que nous avons défini pour les branches de développement est composé des stages suivants :
- Lint du code (eslint)
- Tests unitaires (jest)
- Build des images (docker)
- Déploiement (helm)
- Tests fonctionnels (testcafe)
- Clean (helm, nexus)
Nous nous assurons ainsi que chacun de nos développements respecte une norme ; et qu’il soit validé par les tests unitaires comme les tests fonctionnels.
Le problème
Lorsque nous faisons tourner nos tests en local, Testcafe nous permet de suivre le déroulé du test en ouvrant une nouvelle instance du navigateur. Grâce à cette fenêtre, il est également possible de suivre les logs dans le debugger comme lors d’un développement standard.
Ce confort disparaît lorsque le test tourne dans un container, situé dans un cluster, kubernetes dans notre cas. Plus de fenêtres, plus de logs, le noir complet.
Fatalement, certains de nos jobs de tests plantent parfois sans que l’on sache expliquer la raison au vue des informations disponibles.
En effet, par défaut tout ce que nous avons dans Gitlab sont les logs de nos services backend et les logs générées par testcafe. Ils ne sont pas toujours explicites si le test n’a pas été écrit de manière hyper rigoureuse.
Jusqu’ici, notre façon de reproduire l’erreur était de répéter les différentes étapes du test nous-même sur la stack déployée pour le test. Toutefois, cela demande du temps et n’est pas toujours représentatif car le cas de test n’est pas reproduit dans l’environnement dans lequel il échoue. (dans un container)
Par exemple, il est arrivé que l’erreur provienne d’une pop-in qui apparaissait au-dessus d’un bouton. Cela empêchait le test de progresser dans le cas où la fenêtre était de taille réduite ; ce qui est le comportement par défaut lorsqu’on exécute testcafe dans un container. Dans ce cas, lancer le test en local ne permettait pas de reproduire l’erreur.
La solution
Le framework Testcafe utilisé pour exécuter nos tests d’intégration offre une option permettant de prendre des captures d’écrans et des captures vidéos de la page testée.
Dans Gitlab il est possible de définir des Job artifacts, ce que nous avons fait en précisant le chemin du répertoire à sauvegarder.
Nous avons paramétré Testcafe pour que les vidéos soient persistées en cas d’erreur.
L’option –video nous permet de définir le répertoire dans lequel les vidéos sont sauvegardées.
L’option –video-options prend plusieurs paramètres. Nous définissons les paramètres failedOnly qui vont définir si oui ou non la vidéo sera sauvegardée et pathPattern qui correspond au chemin et au nom du fichier.
De même au niveau des jobs qui lancent nos tests, un “Job artifact” est créé en cas d’erreur du job et nous avons choisi de le conserver durant 8 heures.
Ainsi lorsque l’on se rend sur la page d’un job qui a échoué, une section apparaît (Job artifacts) sur le panel de droite avec 3 boutons:
- Keep
- Download
- Browse
Vous pourrez donc naviguer dans le répertoire sauvegardé pour trouver la ou les vidéos grâce au bouton Browse ou bien télécharger les fichiers.
Puis les visionner dans Gitlab
On remarque ici que la piste à privilégier serait une erreur lors du build du client.
Conclusion
Ajouter l’enregistrement vidéo du test nous aide à identifier le ou les problème(s) rencontré(s) lors du test.
Sauvegarder le répertoire contenant les vidéos nous permet de persister l’enregistrement vidéo et d’y accéder rapidement.
C’est grâce à ces vidéos que nous avons réussi à identifier les problèmes suivants dans nos tests :
- Champs de textes invalides dû à la génération aléatoire de la valeur (caractères non acceptés)
- Des boutons masqués par des notifications
- Le bandeau concernant l’utilisation des cookies masquait également certains éléments
Grâce à la durée de vie réduite des artefacts et le fait que ceux-ci soient conservés uniquement lors d’un échec ; cela permet de maîtriser l’utilisation de notre stockage.
D’autres sujets qui peuvent vous intéresser :
Automatisation et Pipeline CI/CD
La transformation digitale en période de contrainte budgétaire
[…] Un article expliquant l’industrialisation de nos tests. […]