Les tests End to End (de bout en bout) sont une technique utilisée pour vérifier si une application (web, mobile...) se comporte comme prévu, du début à la fin.
Ils consistent à vérifier que l’utilisateur final puisse achever les principaux scénarios d’utilisation de l’application.
Ils sont toutefois à différencier des autres tests connus également réalisables sur le front :
Ici, on se limite uniquement au DOM. Typiquement, le moteur de test E2E va lancer un navigateur pour exécuter les tests.
Le scénario optimal pour mettre en place les teste E2E est d’avoir un cahier des charges avec des scénarios utilisateur clairement définis. Après la période de développement de ces scénarios, les tests E2E permettent leur validation.
Ils sont aussi utiles dans les cas suivants :
Les tests E2E sont limités au DOM. On ne teste donc que ce qui est accessible par l’utilisateur final. Pour certaines fonctionnalités, il vaudra peut-être mieux mettre en place des tests unitaires ou d’intégration.
Certaines mauvaises pratiques peuvent compliquer ou rendre infaisables les tests. Par exemple, s’il n’y a pas d’id
ou de name
sur les champs d’un formulaire, alors un simple déplacement du formulaire dans le fichier HTMLHTML (HyperText Markup Language) est un langage permettant de décrire le découpage d'une page web. fera échouer le test.
Aussi, les tests E2E prennent beaucoup de temps à maintenir ! On ne peut donc pas tester toutes les fonctionnalités dans le cas d’un gros projet.
Bien qu’ils permettent de valider les scénarios utilisateurs, notons qu’ils ne remplacent pas l’utilisateur final.
Plusieurs librairies de tests sont disponibles avec Angular. La plupart se basent sur Jasmine, une librairie JavaScriptLangage de scripting orienté objet servant à uniformiser l’écriture des tests sur le front. Dans le cadre de cet article, nous en avons testé deux, la première basée sur Selenium, Protractor, et la 2nde définissant sa propre architecture, Cypress. (Merci à Boris K. pour la correction ;))
Protractor | Cypress |
---|---|
Inclus avec Angular | Installation via npm (npm install cypress ) |
Interface en ligne de commandes | Interface graphique |
Pas d’attente de base | Ecoute et attente du DOM pour effectuer les actions |
Compilation du projet à chaque lancement de test (même sans changement) | Compilation à chaque changement du projet |
TypeScript | JavaScript / TypeScript |
Après avoir testé les deux librairies, notre choix se porte vers Cypress. L’interface est plus agréable et user-friendly. On peut voir les tests s’exécuter par la librairie, et facilement repérer ceux qui ont échoués. Il affiche également plus de détails sur ce qu’il fait concrètement. Pour avoir plus d’informations, on peut cliquer sur une étape du test pour revenir à l’état de l’application à cet instant.
Ne pas avoir à recompiler le projet à chaque lancement du test est aussi un gain de temps considérable pour le développeur !
Echec d’un test sur Cypress
Réussite d’un test sur Cypress
Interface d’exécution de Cypress
const ipAddress = ’http://192.168.11.77:4200/’;
describe(’Administration Tests’, () => {
beforeEach(() => {
cy.visit(ipAddress + ’administration/admin’)
});
it(’Menu should have 12 children’, () => {
cy.get(’.menu-items-container’).children().should(’have.length’, 12);
});
});
describe
: Décrit un scénario utilisateur. Prend en paramètre une chaine de caractères pour la description, et une fonction contenant la suite de testsbeforeEach()
: S’exécute avant chaque testcy.visit()
: Aller sur l’url donnéeit
: Décrit un test. Prend en paramètre la description du test et une fonction contenant ce qui doit être testécy.get()
: Permet de récupérer un élément du DOM avec un sélecteur CSSchildren()
: Permet de récupérer les enfants de l’élémentshould
: Permet de faire une assertion (ici, on test que le menu a 12 enfants)Le test réalisé ci-dessus est très simple, mais on pourrait imaginer vouloir remplir un formulaire, cliquer sur des boutons, vérifier la bonne couleur d’un composant...
Chez AXOPEN, nous pensons que les tests E2E sont utiles sur des gros projets avec de nombreux scénarios utilisateurs. Ils permettent d’accélérer réellement les tests de non-régression et au cours du développement de l’application.
En revanche, nous ne les recommandons pas leur mise en place sur des plus petits projets, car ils mettent trop de temps à être mis en place et à maintenir, au regard du bénéfice que cela pourrait apporter !
Les tests E2E, c’est quoi ? Définition, implémentation et retour d’expériences des librairies de tests E2E !
Pour bien commencer, une définition s’impose ! Qu’est-ce qu’un @Conditional ? C’est une annotation qui permet de créer des conditions de création d’un Bean. Elle peut être mise sur une classe ou une méthode. Dans cet article, nous allons voir plusieurs t
Pour faire simple, c’est la vitesse d’exécution d’une page. L’enjeu actuel est de faire oublier la présence de la machine derrière l’application, et ainsi, de proposer une expérience utilisateur optimale. On le sait maintenant depuis quelque années, une