Aller au contenu principal

Playbook Testing

StatutActif — v1.0 — 2026-06-27
PrioritéP1
Obligatoire V1Non (backend oui, frontend non)
ResponsableSylvain
Voir aussiStandards · Playbook Playwright

Philosophie​

Tester ce qui compte, pas tout.

Un test inutile coûte autant à maintenir qu'un test utile. L'objectif n'est pas un pourcentage de couverture arbitraire mais la confiance : peut-on déployer sans crainte ?

Règle pratique : si casser ce code silencieusement te ferait transpirer, il mérite un test.

Pyramide des tests DMV​

        ╔══════════╗
        ║  E2E     ║  ← Playwright, parcours critiques seulement
        ║ Playwright║
        ╠══════════╣
        ║Integration║  ← Laravel Feature tests, appels API réels
        ║  Tests    ║
        ╠══════════╣
        ║  Unit    ║  ← Logique métier isolée, transformations
        ║  Tests   ║
        ╚══════════╝

Plus on monte, plus les tests sont lents, fragiles et coûteux à écrire. Garder la base large, le sommet étroit.

Tests unitaires​

Quand les écrire :

  • Logique métier complexe (calculs, transformations, règles métier)
  • Fonctions pures avec plusieurs cas limites
  • Parsing et validation de données

Quand ne pas les écrire :

  • Getters/setters simples
  • Composants UI purement visuels
  • Code trivial qui ne contient aucune logique

Backend Laravel : PHPUnit avec php artisan test. Chaque classe de service complexe mérite ses tests unitaires.

Frontend : optionnel. Utiliser Vitest si le projet a des utilitaires ou hooks complexes.

Tests d'intégration​

Backend :

Les Feature tests Laravel sont la priorité. Ils testent les routes HTTP complètes avec une vraie base de données.

// Exemple DMV — test d'une route API
public function test_liste_acteurs_retourne_200()
{
    $this->actingAs($this->user)
         ->getJson('/api/v1/acteurs')
         ->assertOk()
         ->assertJsonStructure(['data' => [['id', 'nom']]]);
}

Ce qui mérite des Feature tests :

  • Toutes les routes API exposées
  • Les règles d'autorisation (qui peut faire quoi)
  • Les validations de formulaires
  • Les workflows critiques (création, modification, suppression)

Frontend : pas de tests d'intégration frontend obligatoires. Playwright couvre les parcours critiques.

Tests E2E (Playwright)​

Voir Playbook Playwright pour la stratégie complète.

Résumé : uniquement les parcours utilisateurs critiques. Pas de test E2E pour des cas couverts par des tests unitaires ou d'intégration.

Ce qu'on ne teste pas​

  • L'apparence visuelle exacte (snapshots CSS — trop fragiles)
  • Les librairies tierces (elles ont leurs propres tests)
  • Les migrations de base de données (testées en staging et par les Feature tests)
  • Les configurations d'environnement
  • Le code généré automatiquement

Objectif de couverture​

Pas de pourcentage imposé. L'objectif est :

  1. Tous les chemins métier critiques couverts par des Feature tests backend
  2. Tous les parcours utilisateurs critiques couverts par Playwright
  3. Toute logique complexe isolée couverte par des tests unitaires

Un projet peut avoir 40% de couverture globale et être bien testé si les 40% couvrent les bonnes choses.

CI et tests​

Les tests font partie de la CI et bloquent le merge :

  • php artisan test — obligatoire en backend CI
  • Playwright — sur les PRs frontend (required check une fois stabilisé)

Un test qui flake régulièrement doit être corrigé ou supprimé, pas ignoré.