Architecture de framework & CI/CD · Leçon 5 sur 6

Docker & Selenium Grid : des environnements de test reproductibles

« Mais ça marche sur ma machine ! » est l'ennemi d'une CI fiable. Docker met fin à cette dispute — il empaquette tout votre setup de test dans une image qui tourne pareil partout.

Par Shahriyar · Mis à jour

L'idée, en une ligne

Une image Docker regroupe votre version de Python, votre navigateur et vos dépendances ensemble, pour que votre portable et le runner CI tournent exactement le même environnement.

Le Dockerfile, ligne par ligne

▸ try it
# Dockerfile -- a reproducible test image
FROM python:3.12-slim

WORKDIR /app

# Copy deps first so this layer is cached across rebuilds
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# Point tests at a Grid instead of a local browser
ENV GRID_URL=http://selenium-hub:4444/wd/hub

# Default command when the container runs
CMD ["pytest", "-n", "auto", "tests/"]

Lisez-le de haut en bas : partez d'un Python slim, installez les dépendances une fois (mises en cache), copiez le code, et lancez les tests. Copier requirements.txt avant le reste est l'astuce — si seul votre code de test a changé, Docker réutilise l'install en cache au lieu de tout réinstaller.

Avancé — laissez le navigateur vivre ailleurs

Pour les tests UI vous installez rarement les navigateurs à la main. À la place vous pointez un RemoteWebDriver vers Selenium Grid. Grid prend vos commandes et les route vers des instances de navigateur qui tournent ailleurs, pour que vous puissiez exécuter de nombreux navigateurs et versions en parallèle sur plusieurs machines. Ses parties (Router, Distributor, Nodes) acceptent une session et la remettent à un navigateur libre. Les grids cloud comme BrowserStack, Sauce Labs, et LambdaTest offrent la même chose en service hébergé.

Basé sur la référence officielle du Dockerfile (docs.docker.com) et la doc Selenium Grid

Toutes les leçons de Architecture de framework & CI/CD

  1. Concevoir un framework de zéro : les couches
  2. Les quatre patterns que les SDET utilisent vraiment
  3. Données de test : fixtures vs factories vs ensemencement
  4. CI avec GitHub Actions : exécuter UI + API à chaque push
  5. Docker & Selenium Grid : des environnements de test reproductibles
  6. Parallèle, réessais & quarantaine des tests instables