Stratégie de Tests & Conventions (Front)

1. Philosophie & Règle générale

Afin de garantir la stabilité de l’interface utilisateur, la robustesse des flux de données réactifs et la non-régression de l’application Berth Front, une séparation claire des responsabilités de test est appliquée.

Règle d’or

L’intégralité du code front-end (services, logique métier, composants isolés, pipes, utilitaires, intercepteurs) est testée unitairement et en intégration via Vitest. Seules les pages routées (*.page.ts) et les parcours critiques complets sont testés de bout en bout via Playwright.

Type de test	Outil	Périmètre cible	Localisation
Unitaires & Intégration	Vitest	Services HTTP, stores Signals, composants réutilisables (components/), Signal Forms, intercepteurs, pipes, utils	tests/vitest/
End-to-End (E2E)	Playwright	Pages routées (*.page.ts), navigation, flux d’authentification, scénarios utilisateur réels dans le navigateur	tests/e2e/

---

2. Organisation & Arborescence du dossier tests/

Tous les tests du projet sont centralisés à la racine de l’application dans un dossier dédié tests/, scindé en deux sous-dossiers distincts :

berth-front/
├── src/
│   └── app/
│       ├── core/
│       ├── shared/
│       └── features/
│           └── applications/
│               ├── pages/applications.page.ts
│               ├── components/app-card.component.ts
│               └── services/application.service.ts
└── tests/
    ├── e2e/                      # Tests End-to-End Playwright (pages et scénarios complets)
    │   ├── auth.spec.ts          # Parcours de connexion et gestion des sessions
    │   ├── applications.spec.ts  # Validation de la page applications et interactions réelles
    │   └── containers.spec.ts    # Cycle de vie des conteneurs via l'interface
    └── vitest/                   # Tests unitaires et d'intégration Vitest
        ├── core/                 # AuthInterceptor, RealtimeService, AuthService
        ├── features/             # Services HTTP, composants de feature, logique Signal Forms
        └── shared/               # Composants UI partagés, directives, pipes, helpers

---

3. Découpage technique des tests

3.1 Tests avec Vitest (tests/vitest/)

Vitest est configuré pour s’exécuter dans un environnement 100 % Zoneless avec Angular 20. Il valide la logique sans instancier de navigateur lourd, assurant une vitesse d’exécution maximale.

Couche testée	Rôle & Approche	Exemples de validation
Services HTTP (*.service.spec.ts)	Validation des requêtes HTTP, headers et mapping des DTOs	Utilisation de provideHttpClient() et HttpTestingController pour vérifier les URLs, méthodes et payloads.
Gestion d’état & Signals	Validation des signal(), computed() et flux asynchrones toSignal()	Vérification des transitions d’état réactives et du comportement zoneless sans mutations muettes.
Signal Forms	Contrôle des schémas de validation et états du formulaire	Validation des règles required, pattern, de la validité globale form().valid() et du reset.
Composants isolés (*.component.spec.ts)	Validation de la logique de présentation et des @Input() / @Output()	Montage du composant avec le TestBed, vérification des liaisons d’événements et du rendu DOM.
Intercepteurs & Core	Validation de l’injection du token JWT et de la gestion globale des erreurs	Contrôle de l’ajout du header Authorization et redirection en cas de code 401.

3.2 Tests avec Playwright (tests/e2e/)

Playwright valide le comportement réel dans les moteurs de rendu (Chromium, Firefox, WebKit) en ciblant exclusivement les pages :

Périmètre testé	Rôle & Approche	Exemples de scénarios
Pages routées (*.page.ts)	Rendu initial, lazy-loading des routes et affichage des vues	Chargement de la page /applications, vérification des titres, tableaux et états de chargement.
Authentification & Session	Flux complet de connexion, persistance du token et déconnexion	Saisie des identifiants, vérification de la redirection vers le tableau de bord et protection des routes.
Parcours critiques	Interactions multi-composants et opérations sensibles	Création d’une application, modification de configuration et validation des retours visuels.

---

4. Bonnes pratiques & Règles d’écriture

4.1 Spécificités Zoneless sous Vitest

En mode Zoneless, la détection des changements ne repose plus sur zone.js :

• Utiliser fixture.detectChanges() ou laisser les Signals propager automatiquement les mises à jour.
• Toujours privilégier les mises à jour immuables des Signals (model.update(v => ({ ...v, key }))).

4.2 Isolation des tests E2E Playwright

• Utiliser des sélecteurs stables basés sur les rôles et attributs sémantiques (page.getByRole(), page.getByTestId()).
• Préparer ou réinitialiser l’état via des fixtures Playwright dédiées avant l’exécution des scénarios.

---

5. Outils & Commandes utiles

Outil / Pratique	Usage	Description & Rôle
Vitest	Tests unitaires & intégration	Moteur de test ultra-rapide basé sur esbuild/Vite, natif ESM.
Playwright	Tests End-to-End	Automatisation cross-browser pour la validation des pages et scénarios réels.
HttpTestingController	Mocking réseau Vitest	Interception et simulation des réponses de l’API Berth pour les services.

Commandes d’exécution

# Exécuter tous les tests unitaires et intégration (Vitest)
npm run test:unit
# ou directement
npx vitest run

# Exécuter les tests Vitest en mode watch
npx vitest

# Exécuter les tests avec couverture de code
npx vitest run --coverage

# Exécuter les tests End-to-End (Playwright) sur les pages
npm run test:e2e
# ou directement
npx playwright test

# Exécuter Playwright avec interface graphique (UI Mode)
npx playwright test --ui