Tester notre application frontend avec Playwright

Pourquoi tester

Ajouter des tests à notre code permet bien entendu d’augmenter la qualité et la fiabilité de ce dernier. Mais la raison la plus importante est que les tests permettent d'être confiant sur l’ajout de fonctionnalités futures ou de refactorisation en assurant que notre code continue de fonctionner convenablement.

‍

Les types de tests

Sans rentrer dans les détails, car ce n’est pas le but de l’article, il est important de rappeler qu’il existe différents types de tests qui sont adaptés pour différents cas d’utilisation.

‍

Tests statiques

Les tests statiques sont effectués sans nécessiter l’exécution du code. Cela permet de détecter très rapidement et à moindre coût les fautes de frappe, les typages incorrect…

Des langages de programmation typés (TypeScript, Flow) ou des Linter (ESLint) peuvent effectuer ce type de tests.

‍

Tests unitaires

Comme leur nom l’indique ils permettent de tester unitairement une petite partie du code (une fonction, une classe, un composant…). Ils sont simples à mettre en œuvre et sont exécutés très rapidement.

Outils : JEST, Mocha, AVA

‍

Tests d’intégration

Les tests d’intégration permettent de valider que plusieurs composants, entités de code interagissent entre eux correctement.

Outils : JEST, Mocha, AVA

‍

Tests E2E

Les tests E2E (end-to-end) ou fonctionnels sont beaucoup plus poussés, ils simulent dans un environnement complet des actions de l’utilisateurs. Ils permettent de tester des scénarios précis de l’application (authentification, consultation d’un solde, soumission d’un formulaire…).

Outils : Cypress, PlayWright, Puppeteer

Pour plus d’informations sur le sujet je vous conseille l’article « The Testing Trophy and Testing Classifications » de Kent C.

‍

Tests manuels

Enfin les tests manuels, couteux en temps, mais qui permettent de valider humainement la livraison d’une nouvelle fonctionnalité.

‍

Playwright

‍

Un des avantages de playwright est qu’il permet de réaliser des tests sur les différents navigateurs du marché, Chromium, Firefox, et Webkit (Safari) même sur Windows contrairement à son concurrent Cypress.

Il permet facilement d'émuler certains périphériques.

npx playwright open --device="iPhone 12" --lang="es-ES" wikipedia.org

‍

Mise en place d’un test

Nous avons testé Playwright sur une application web existante. La mise en place des tests se fait plutôt facilement et de manière intuitive

Installation avec la commande init npm init playwright@latest

Cette commande va se charger d’installer les Playwright et les différents navigateurs, de créer un fichier de configuration et un premier fichier de test example.spec.ts.

Nous allons modifier ce fichier pour notre besoin:

‍

import { test, expect } from '@playwright/test';


test('Redirect to the login page on first app launch', async ({ page }) => {
  await page.goto('http://localhost:3000/');
  await expect(page).toHaveURL('http://localhost:3000/authentication/login');
});

test('Redirect to the home page after login', async ({ page }) => {
  await page.goto('http://localhost:3000');
  await page.fill('input[name="mobile-phone"]', '0651155458');
  await page.fill('input[name="password"]', 'password');
  await page.click('ion-button[type="submit"]');
  await expect(page).toHaveURL('http://localhost:3000/home');
});

‍

Il suffit maintenant de lancer les tests avec la commande npx playwright test

‍

Codegen

Playwright possède également un mode permettant de générer du code test de façon automatique.

Pour ce faire, lancer la commande npx playwright codegen http://localhost:3000

Votre webapp devrait s’ouvrir, ainsi que l’inspecteur Playwright, il vous suffit simplement de réaliser les actions sur la webapp pour voir vos interactions s’écrire automatiquement dans l’inspecteur.

‍

Notre avis

Playwright est un outil vraiment simple à prendre en main, de plus la documentation est étoffée et claire, il est facile de retrouver les informations qui nous sont nécessaires.

On pourra juste lui reprocher une communauté moins active que des solutions comme Cypress ou Pupetter où il est relativement facile de trouver une réponse à un problème.

‍

Quoi tester ?

Une des grandes difficultés des tests dit “haut niveau” (interface, manuel) est de maintenir un environnement de test complet avec des jeux de tests figés. L’environnement de test doit être le plus similaire possible à l’environnement de production.

Il n’est pas nécessaire de tester 100% du scope de l’application car cela serait très couteux, mais une majorité de fonctionnalités judicieusement choisies. Cela permet de garantir la non-régression et d’éviter d’accumuler de la dette technique suite à des ajouts, modification de fonctionnalités.

‍

Automatisation

L’ensemble des tests peut et doit être joué automatiquement par une chaine d’intégration continue. Cela permet de découvrir les erreurs au fil du développement de l’application car les tests seront joués à chaque commit, on minimise donc les risques d’erreur humaine.

Envie d’en savoir plus ? Notre équipe est à votre écoute pour en discuter davantage et vous aider à faire le bon choix de solutions en fonction de votre contexte, de vos contraintes et de vos enjeux. N’hésitez pas à nous contacter via notre formulaire de contact.

‍