Files

jpgiannetti 1a67e5ffd0 chore(docs): supprimer liens cassés vers fichiers inexistants

Suppressions/corrections:
- Suppression références ADR inexistants (010, 011, 018-notifications-push)
- Suppression liens vers fichiers d'analyse supprimés (ANALYSE_LIBRAIRIES_GO.md, INCONSISTENCIES-ANALYSIS.md)
- Correction numéros ADR: 010→012, 018→020, 020→022
- Correction liens relatifs dans domains/README.md
- Suppression référence regles-metier/ (structure legacy)

Script: scripts/remove-broken-links.sh

2026-02-07 17:31:30 +01:00

3.4 KiB

Raw Permalink Blame History

ADR-013 : Stratégie Tests

Statut : Accepté Date : 2025-01-20

Contexte

RoadWave nécessite une couverture tests robuste avec documentation vivante des use cases. La stratégie doit équilibrer vélocité développement et qualité.

Décision

Approche multi-niveaux : unitaires, intégration, BDD (Gherkin), E2E, load testing.

Stratégie par type

Type	Framework	Cible	Fréquence
Unitaires	Testify	80%+ couverture	Chaque commit
Intégration DB	Testify + Testcontainers	Repositories critiques	Avant merge PR
BDD (Gherkin)	Godog	User stories	Avant release
E2E Mobile	Flutter integration_test	Parcours critiques	Nightly
Load	k6	N/A	Avant mise en prod

Tests unitaires (Testify)

Framework : github.com/stretchr/testify
Couverture minimale : 80% sur packages internal/*/service.go
Exécution : Chaque commit (CI rapide ~30s)

Tests BDD (Gherkin + Godog)

Framework : github.com/cucumber/godog
Couverture : Tous les cas d'usage du traduits en .feature
Exécution : Avant release
Détails : Voir ADR-007 pour contexte complet

Tests intégration (Testcontainers)

Framework : github.com/testcontainers/testcontainers-go
Scope : Repositories avec PostGIS/Redis (requêtes spatiales complexes)
Exécution : Avant merge PR
Justification : Validation des requêtes PostGIS impossibles à mocker

Tests E2E Mobile (Flutter)

Framework : integration_test (Flutter officiel)
Scope : Parcours critiques (authentification, lecture audio, géolocalisation)
Exécution : Nightly builds
Justification : Validation de l'intégration complète mobile + backend

Load testing (k6)

Framework : grafana/k6
Objectif : API p99 < 100ms à 10K RPS
Scénarios : Recommandations géolocalisées, streaming HLS, authentification
Exécution : Avant mise en production

Alternatives considérées

Approche	Avantages	Inconvénients	Décision
Tests unitaires uniquement	Rapides, simples	Pas de validation intégration	❌ Insuffisant pour PostGIS
TDD strict (100% couverture)	Qualité maximale	Vélocité réduite (-40%)	❌ Trop coûteux pour MVP
BDD sans tests unitaires	Documentation vivante	Feedback lent (3-5min/run)	❌ Cycle développement trop lent
Stratégie multi-niveaux	Équilibre qualité/vitesse	Complexité CI/CD	✅ Choisi

Justification

80% unitaires : Feedback rapide (<30s), détection précoce des régressions
BDD : Documentation vivante alignée avec les règles métier
Testcontainers : Seule façon fiable de tester PostGIS ST_DWithin, ST_Distance
E2E ciblés : Validation des parcours critiques sans ralentir le développement
k6 : Détection des régressions de performance avant production

Conséquences

Dépendances :
- github.com/stretchr/testify
- github.com/cucumber/godog
- github.com/testcontainers/testcontainers-go
- grafana/k6 (AGPL-3.0, usage interne OK)
Temps CI : ~3-5 min (tests unitaires + BDD)
Tests intégration/E2E : nightly builds (15-30 min)
Load tests : avant chaque release majeure

Librairies : Voir ADR-018 pour analyses complètes des frameworks de tests

3.4 KiB Raw Permalink Blame History