Tests avec Puppeteer

Aller encore plus loin avec Puppeteer #

Que l’application soit conteneurisée ou non, on peut lancer des tests fonctionnels avancés à destination d’un environnement de recette. Les tests fonctionnels suivent un scénario décrit en utilisant la syntaxe de la librairie Puppeteer qui tourne sous NodeJS, et qui viendra simuler le comportement d’un utilisateur grâce à un navigateur headless (Browserless).

Pour une application déployée en mode classique (sans conteneur), les tests seront déclenchés POST déploiement. Il est nécessaire de bénéficier d’un environnement iso à la production pour que les tests soient reproductibles.

Dans l’exemple ci-dessous, on utilise la CI pour automatiser des tests fonctionnels après un déploiement de l’application sur un serveur de recette. Comme d’habitude, la CI va utiliser des conteneurs pour lancer les tests.

Scénariser les tests dans l’application #

La librairie définit des règles d’écriture qui permettent de scénariser le comportement avancé d’un utilisateur. Ici, on vient simplement regarder si la home de notre application sur le serveur d’intégration contient ce qu’il faut.

• Contenu du fichier tests/browser.test.js dans notre application:

describe("TESTING", () => {
  beforeAll(async () => {
    if (!process.env.URL) {
      throw "ENV key URL is missing";
    }

    const url = process.env.URL.startsWith("https://")
      ? process.env.URL
      : `https://${process.env.URL}`;

    await page.goto(url);
  });

  it('should display "Bearstech" text on page', async () => {
    await expect(page).toMatch("Bearstech");
  });
});

Afin de simuler les tests dans un navigateur headless, nous utiliserons l’image Docker de Browserless. Il faut donc renseigner aussi le nom du service qui sera utilisé par le conteneur:

• Contenu du fichier tests/jest-puppeteer.config.js

module.exports = {
  connect: {
    browserURL: process.env.BROWSERLESS_URL
      ? process.env.BROWSERLESS_URL
      : "http://browserless:3000",
  },
};

Définir l’image qui implémentera les tests #

Cette image sera buildée dans la CI afin d’être disponible pour l’exécution de Puppeteer.

• Contenu du fichier Dockerfile qui lancera les tests dans node

FROM bearstech/node-dev:16
RUN mkdir /tests
WORKDIR /tests
COPY tests/ /tests/
RUN yarn install
CMD ["yarn", "test"]

Intégrer les services dans un Docker-compose #

• Contenu du fichier docker-compose.yml utilisé pour lancer les services de tests

version: "3"

services:
  browserless:
    image: browserless/chrome
    expose: [3000]

  pupeteer:
    image: ${CI_REGISTRY_IMAGE}/pupeteer:latest
    depends_on:
      - browserless

Lancer les tests dans la CI #

• Extrait du Makefile

tests:
    $(COMPOSE) up -d browserless && sleep 2
    $(COMPOSE) run --rm -u $(UID) -e URL="$(URL)" pupeteer

• Extrait du .gitlab-ci.yml de la pipeline d’intégration

tests-integration:
    stage: test
    variables:
      URL: https://<myapp>.staging.bearstech.com
    script:
      # run our test
      - make tests

Ici, la commande écrite dans un Makefile attend que le conteneur de Browserless soit disponible avant de lancer les tests dans l’image qui instancie Puppeteer. L’url qui servira de point de départ au scénario est définie en tant que variable dans le fichier .gitlab-ci.yml.

Ce test fonctionnel est bloquant dans la CI, c’est à dire qu’en cas d’échec, le pipeline s’arrête et les étapes définies après ne sont pas exécutées. Ceci peut être utile pour empêcher le déploiement de l’application sur les environnements de production quand le scénario rencontre un imprévu.