Files

T

Johan LEROY 0284cc0cd8 docs: décrit la CI unifiée, l'e2e, la charge et la supervision

- ADR 0014 : un pipeline CI unique, « CI ok » seul check à exiger, déploiement du commit testé.
- ADR 0015 : e2e et charge contre la stack Compose déployée, hypothèses et seuils de k6.
- ADR 0016 : supervision en profil Compose, active en prod, rôle en lecture seule.
- Nouvelle vue 60-observabilite.md ; 00-vue-ensemble, 10-infra, 20-backend et 50-cicd mis à
  jour (monitoring passé à Fait, nouveau graphe de CI, gates, ports).
- README racine et guide de tests du frontend : où sont l'e2e, la charge et la supervision.

2026-09-23 09:46:12 +02:00

3.3 KiB

Raw Blame History

Conventions de tests unitaires : Frontend

Outil

Vitest (intégré nativement à Angular CLI, pas d'installation à faire).

Où écrire les tests

Un fichier *.spec.ts à côté de chaque fichier testé (convention Angular CLI par défaut, respectée automatiquement par ng generate).

Structure attendue (Arrange / Act / Assert)

it('devrait faire X quand Y', () => {
  // Arrange : préparer les données et les mocks
  const input = { valeur: 42 };

  // Act : exécuter le code testé
  const result = service.doSomething(input);

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

Ce qui doit être testé en priorité

Services (core/services/) : logique métier, gestion des erreurs
Guards et interceptors (core/guards/, core/interceptors/) : chaque branche de décision
Composants avec logique (formulaires, conditions d'affichage) — pas nécessaire pour un composant 100% template, sans logique

core/services/, core/guards/ et core/interceptors/ n'existent pas encore : c'est l'arborescence cible, décrite dans docs/architecture/30-frontend.md.

Gabarit — tester un service avec appel HTTP

import { TestBed } from '@angular/core/testing';
import { provideHttpClient } from '@angular/common/http';
import { provideHttpClientTesting, HttpTestingController } from '@angular/common/http/testing';
import { MonService } from './mon.service';

describe('MonService', () => {
  let service: MonService;
  let httpMock: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [MonService, provideHttpClient(), provideHttpClientTesting()],
    });
    service = TestBed.inject(MonService);
    httpMock = TestBed.inject(HttpTestingController);
  });

  afterEach(() => httpMock.verify());

  it('devrait récupérer les données', () => {
    service.getData().subscribe();
    const req = httpMock.expectOne('/api/v1/...');
    expect(req.request.method).toBe('GET');
    req.flush({ /* réponse simulée */ });
  });
});

Gabarit — tester un composant standalone

import { TestBed } from '@angular/core/testing';
import { MonComposant } from './mon-composant';

describe('MonComposant', () => {
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      imports: [MonComposant],
    }).compileComponents();
  });

  it('devrait se créer', () => {
    const fixture = TestBed.createComponent(MonComposant);
    expect(fixture.componentInstance).toBeTruthy();
  });
});

Lancer les tests

Développement (mode watch) : npm test
Rapport de couverture (CI) : npm run test:ci -- --coverage, puis ouvrir coverage/index.html
Un fichier ou un dossier seulement : npx ng test --watch=false --coverage=false --include=src/app/core/services/alerts.service.spec.ts (répéter --include pour plusieurs cibles ; un dossier joue tous ses specs)

Au-delà des tests unitaires

Les parcours utilisateur complets (connexion, rôles, sites, recommandations, alertes) sont testés de bout en bout par Playwright, contre l'API et le proxy réels : voir tests/e2e/README.md. Un élément sans rôle ni libellé stable que ces parcours doivent viser reçoit un data-testid.

3.3 KiB Raw Blame History