Les tests automatisés

• Anti-régression : tu modifies une fonction, le test te dit immédiatement si tu casses l'existant
• Refacto sereine : tu changes l'implémentation sans changer le comportement, les tests verts valident
• Documentation vivante : un test bien nommé décrit l'intention métier mieux qu'un commentaire
• Confiance en prod : merger un vendredi soir sans avoir la boule au ventre
• Feedback de design : un code difficile à tester est souvent un code mal découpé

• Unitaires (≈ 70 %) : rapides (ms), isolés, testent une fonction pure ou une classe
• Intégration (≈ 20 %) : vérifient que plusieurs modules collaborent (DB, API interne)
• End-to-end (≈ 10 %) : simulent un·e utilisateur·ice à travers toute la stack

Quel test pour quel cas

• Une fonction de calcul (ex : TVA, panier) → unitaire
• Une couche d'accès à une base ou un appel d'API interne → intégration
• Un parcours utilisateur critique (login, paiement) → e2e

AAA : Arrange, Act, Assert

import { describe, it, expect } from 'vitest';
import { calculerTVA } from './tva';

describe('calculerTVA', () => {
  it('applique 20% sur un montant HT', () => {
    // Arrange : préparer les données et le contexte
    const ht = 100;

    // Act : exécuter la fonction testée
    const ttc = calculerTVA(ht, 0.2);

    // Assert : vérifier le résultat
    expect(ttc).toBe(120);
  });
});

Les règles d'un bon test unitaire

• Isolation : pas de DB, pas de réseau, pas d'horloge réelle
• Déterministe : 100 exécutions = 100 résultats identiques
• Rapide : on doit pouvoir lancer toute la suite en quelques secondes
• Nom clair : it('renvoie 0 quand le panier est vide') > it('test calcul')
• Une seule chose testée : un test = un comportement attendu

Mocks et spies pour isoler

import { vi } from 'vitest';
import { envoyerEmail } from './email';
import { creerUtilisateur } from './users';

vi.mock('./email');

it('envoie un email de bienvenue à l\'inscription', async () => {
  await creerUtilisateur({ email: 'alice@exemple.fr' });
  expect(envoyerEmail).toHaveBeenCalledWith({
    to: 'alice@exemple.fr',
    template: 'bienvenue',
  });
});

Le cycle en 3 étapes

1. Red : tu écris un test qui échoue (la fonction n'existe pas encore, ou ne fait pas ce qu'il faut)
2. Green : tu écris le minimum de code pour passer au vert. Pas plus.
3. Refactor : tu nettoies le code et les tests, sans changer le comportement

Baby steps

Un comportement à la fois, pas dix cas d'un coup. Tu ajoutes un test, tu fais passer, tu nettoies. Boucle suivante. Au début ça paraît lent, à la fin du projet tu as un design propre, modulaire, testable.

Exemple : implémenter un panier en TDD

import { describe, it, expect } from 'vitest';
import { Panier } from './panier';

describe('Panier', () => {
  it('a un total de 0 quand il est vide', () => {
    const panier = new Panier();
    expect(panier.total()).toBe(0);
  });
});

export class Panier {
  total() {
    return 0;
  }
}

Oui, c'est ridicule au début. Mais à l'étape 3 (refactor) puis aux étapes suivantes (ajout, suppression, remise), tu vas construire un Panier solide, fonctionnalité par fonctionnalité, toujours sous filet.

Le piège à éviter

Le pattern fixtures + rollback

import { describe, it, expect, beforeEach } from 'vitest';
import { db } from './db';
import { creerUtilisateur } from './users';

beforeEach(async () => {
  await db.user.deleteMany();
});

it('persiste un utilisateur en base', async () => {
  const u = await creerUtilisateur({ email: 'alice@exemple.fr' });

  const trouve = await db.user.findUnique({ where: { id: u.id } });
  expect(trouve?.email).toBe('alice@exemple.fr');
});

Variante plus propre : encadrer chaque test par une transaction qui se termine par un ROLLBACK. Tu repars d'un état strictement identique à chaque fois, sans avoir à supprimer manuellement.

Tests d'API HTTP

import { describe, it, expect } from 'vitest';
import request from 'supertest';
import { app } from './app';

it('POST /commandes crée une commande', async () => {
  const res = await request(app)
    .post('/commandes')
    .send({ produitIds: [1, 2] })
    .set('Authorization', 'Bearer test-token');

  expect(res.status).toBe(201);
  expect(res.body).toMatchObject({ id: expect.any(Number) });
});

Pourquoi Playwright en 2025

• Auto-waiting : Playwright attend que l'élément soit prêt, pas de sleep manuel
• Locators sémantiques : getByRole, getByLabel, résistants au refactor UI
• Multi-navigateurs : Chrome, Firefox, Safari, en parallèle
• Trace viewer : visualisation pas-à-pas d'un test rouge en CI
• Isolation : chaque test = un contexte navigateur neuf

Exemple : parcours d'inscription

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

test('un·e visiteur·euse peut s\'inscrire', async ({ page }) => {
  await page.goto('/signup');

  // Locators sémantiques : se basent sur l'accessibilité
  await page.getByLabel('Email').fill('test@exemple.fr');
  await page.getByLabel('Mot de passe').fill('Secret123!');
  await page.getByRole('button', { name: 'Créer mon compte' }).click();

  // Auto-waiting : on attend que l'écran de bienvenue apparaisse
  await expect(
    page.getByRole('heading', { name: 'Bienvenue' }),
  ).toBeVisible();
});

Ce qui vaut un test e2e

• Login / signup
• Paiement, processus checkout
• Création d'une ressource critique (commande, ticket, dossier)
• Pas : les variations de couleur, les hovers, les détails CSS (trop fragile)

Les métriques

• Lines : % de lignes exécutées par les tests (trompeur)
• Branches : % de branches conditionnelles (plus utile)
• Functions : % de fonctions appelées
• Statements : % d'instructions

# Vitest avec couverture
npx vitest run --coverage

Le seuil raisonnable

70 à 85 % sur le code métier suffit largement. Pour une lib critique (paiement, crypto), pousse à 95+. Mais ne vise jamais 100 % juste pour le chiffre.

Mutation testing : la vraie mesure de qualité

Outils comme Stryker : ils modifient ton code volontairement (changent un > en <, par exemple) et vérifient si tes tests le détectent. Si non, tes tests sont faibles. C'est la métrique la plus exigeante.

Le workflow type

name: Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  unit-integration:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run test:unit -- --coverage
      - run: npm run test:integration

  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run test:e2e
      - uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: playwright-traces
          path: test-results/

Stratégie selon la vitesse

• Unit + intégration : bloquants sur chaque PR
• E2E rapide (parcours critiques) : bloquant sur chaque PR
• E2E lent (suite complète) : nightly ou hebdo, avec alerte Slack si rouge