Tests et intégration continue

Les tests suivent les limites d’architecture : règles métier sans framework, adaptateurs testés à leur frontière, composants en boîte noire et parcours E2E réservés aux intégrations réelles.

Pyramide frontend

Niveau	Outil	Ce qu’il protège
Domaine et application	Vitest	règles, cas d’usage, erreurs et transitions
Repositories et mappings	Vitest	contrat JSON, URL, auth et conversions
View models	Vitest	formatage français, dates, tailles et labels
Composants	Testing Library Svelte	rendu, accessibilité et interactions
États visuels	Storybook	variantes réalistes et régression manuelle
Routes serveur	Vitest sur helpers purs	parsing, rôle, erreur et payload d’action
Parcours	Playwright	SSR, cookies, navigation et intégration

Les tests vivent près du code (*.test.ts). Extrayez la logique d’une route dans un helper pur exporté avec un préfixe _ plutôt que de simuler un RequestEvent complet.

Commandes frontend

npm run check          # Paraglide, svelte-kit sync et svelte-check
npm run lint           # Prettier puis ESLint
npm run test           # Vitest complet
npm run build          # bundle de production
npm run test:e2e       # Playwright
npm run docs:check     # Astro check et formatage
npm run docs:build     # génération statique de la documentation
make verify            # check + lint + tests + build + docs:check

Pendant l’implémentation, exécutez un fichier ciblé :

npm run test -- src/lib/application/media/GetMediaLibraryUseCase.test.ts

Ne terminez pas la tâche avec seulement ce test ciblé.

E2E back-office

Les scénarios authentifiés utilisent des fichiers Playwright storageState fournis par variables d’environnement, par exemple E2E_BACKOFFICE_STORAGE_STATE_A ou E2E_BACKOFFICE_AUTHOR_STORAGE_STATE. Sans ces fichiers, les scénarios concernés sont ignorés de façon explicite.

Chaque suite back-office conserve au moins un test non authentifié vérifiant la redirection vers /login. Pour les données backend, utilisez page.route et des fixtures contrôlées lorsque le but du test est l’écran ; utilisez le vrai backend seedé lorsque le but est le parcours cross-stack.

Le job CI Browser smoke utilise l’image mcr.microsoft.com/playwright:v1.59.1-noble : Chromium et les bibliothèques système sont déjà installés. N’ajoutez pas playwright install --with-deps dans ce job.

Pyramide backend

Niveau	Commande	Portée
Format	make fmt-check	fichiers non formatés
Analyse	make vet staticcheck	défauts Go et règles statiques
Unitaires	make test-unit	tous les packages sauf intégration
Intégration	make test-integration	migrations, repositories et HTTP
Contrat	make contract	structure OpenAPI obligatoire
Compilation	make build	tous les packages
Complet	make verify	chaîne précédente dans l’ordre

Les tests unitaires ont un timeout par défaut de cinq minutes. Les tests d’intégration ont dix minutes et un parallélisme limité à deux. Surchargez temporairement ces variables pour le diagnostic, pas pour contourner un blocage systématique.

Tests d’intégration backend

Une suite d’intégration :

1. crée une application PocketBase isolée ;
2. applique les migrations réelles ;
3. insère uniquement les données nécessaires ;
4. exerce repository, service ou handler ;
5. vérifie résultat et effets persistés ;
6. nettoie son répertoire temporaire.

Évitez une dépendance à backend/pb_data, qui appartient au développeur et rend les tests non reproductibles.

E2E cross-stack local

Depuis HarmonyV2/ :

make e2e

La cible seed le backend, le démarre sur 127.0.0.1:8090, attend jusqu’à soixante secondes la route /api/hello, puis lance les tests web. Le log backend est écrit dans /tmp/harmony-backend-e2e.log et le processus est arrêté à la fin.

CI GitHub Actions

Web — Build & Test

1. checkout ;
2. Node selon .nvmrc avec cache npm ;
3. installation application et documentation ;
4. type check, lint, tests unitaires et build ;
5. check puis build Starlight.

PUBLIC_MAPTILER_KEY=ci-placeholder exerce les routes utilisant la configuration publique sans exposer une clé réelle.

Web — Browser smoke

Ce job indépendant installe les dépendances, construit l’application et exécute uniquement e2e/ci-smoke.test.ts avec un worker en CI.

Backend — Build & Test

Le job configure Go depuis .go-version, installe la version épinglée de staticcheck, puis exécute analyse, unitaires, intégration, contrat et build.

Les workflows tournent sur toute PR et sur les pushes vers develop et main. La concurrence annule l’ancien run d’une même branche.

Diagnostiquer un échec

1. Identifiez la première commande en échec, pas la dernière ligne du job.
2. Reproduisez exactement cette commande avec la même version de runtime.
3. Vérifiez si l’échec est déterministe en relançant le test ciblé localement.
4. Consultez trace, capture, logs et sortie backend disponibles.
5. Corrigez la cause puis exécutez le groupe complet concerné.
6. Terminez par make verify et les E2E requis.

Un timeout de fermeture PostHog ou un téléchargement de navigateur lent se corrige dans la gestion du client ou l’image CI, pas avec un retry général du workflow.

Tests instables

Un retry n’est acceptable que pour une dépendance externe identifiée et après conservation des preuves du premier échec. Pour une instabilité interne :

• éliminez temps réel et hasard non contrôlés ;
• utilisez une horloge injectée ;
• attendez un état observable plutôt qu’un délai fixe ;
• isolez les données et ports ;
• évitez le partage d’un singleton mutable entre tests.