Dans ce billet, nous allons discuter d’un sujet crucial pour les développeurs et les testeurs : la pertinence des tests de bout en bout (ou end-to-end E2E) web.
En effet, lorsqu’il s’agit de tester des applications web, les tests automatisés jouent un rôle vital, car ils peuvent être exécutés à plusieurs reprises sans effort et manuel supplémentaire. Parmi les tests automatisés, les tests bout en bout sont particulièrement importants, car ils simulent des cas d’utilisation réels. Cependant, il existe des pratiques courantes qui limitent la pertinence de ces tests.
Nous allons ici examiner 3 mauvaises pratiques, ou erreurs courantes, qui limitent la pertinence de vos tests de bout en bout.

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

Présentation de Monkeyble: framework de test bout en bout pour Ansible

Monkeyble est un petit framework qui permet de tester de bout en bout vos playbooks Ansible.

Il permet, au niveau des tâches des Playbooks, de:

• 🐵 Vérifier qu'un module a été appelé avec les bons arguments ;
• 🙊 Vérifier le résultat du retour d'un module ;
• 🙈 Vérifier l'état d'exécution d'une tâche (changed, skipped, failed) ;
• 🙉 Simuler (Mock) un module afin de retourner un résultat sans faire appel au vrai module.

Monkeyble est tout particulièrement conçu pour être placé dans une CI/CD afin de détecter les éventuels régressions lors des modifications sur une base de code Ansible 🚀.

La compilation du noyau Linux est souvent présentée comme étant triviale : un appel à make et c’est réglé.

Cependant les choses se compliquent vite si l’on souhaite :

• cross-compiler
• utiliser différentes toolchains (ou versions)
• reproduire une compilation sur une autre machine
• utiliser une toolchain non-supportée par sa distribution
• …

En connaissant bien le fonctionnement de sa distribution et les règles de compilations du noyau Linux, c’est tout à fait faisable même si cela reste fastidieux. D’ailleurs, beaucoup de développeurs du noyau possèdent un jeu de scripts maison pour cela.

Afin de rendre cela accessible à tous, Linaro a créé et maintient TuxMake.

De l’eau a coulé sous les ponts pour Cerberus depuis la dernière annonce sur LinuxFr.org (2014). Pour rappel, Cerberus est une application Java/MariaDB en mode Web qui permet de gérer et concevoir des tests automatisés pour des applications sur technologies Web, natives en mode desktop, mais aussi sur mobiles iOS et Android. Cerberus permet également de faire des tests de services Web (SOAP, REST, JSON, mais aussi Apache Kafka sur des opérations de production et recherche d’événements dans des topics).

Cerberus fait partie des logiciels dits de Low code testing (test avec peu de code) et a pour objectif de mettre l’automatisation de tests dans les mains de personnes qui n’ont pas le temps ou les compétences pour écrire des tests dans un langage de programmation.

Pas besoin d’un IDE, d’un compilateur ni même d’une infrastructure de test. Il faut juste l’adresse URL de l’outil avec un identifiant et un mot de passe, et les premiers tests peuvent être créés et lancés simplement.

La version 4.7 ajoute principalement la capacité de contrôler le trafic réseau généré par l’application testée. Elle ajoute sur ce thème de nombreux rapports et tableaux de bord qui facilitent l’analyse des cas de tests.

La seconde partie de la dépêche détaille les fonctionnalités disponibles, mais elle explique également les enjeux et contraintes d’automatisation de tests pour l’analyse et les performances sur un site Web.