roadwave/docs/adr/015-strategie-tests.md

ADR-015 : 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 README.md 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
• Temps CI : ~3-5 min (tests unitaires + BDD)
• Tests intégration/E2E : nightly builds (15-30 min)
• Load tests : avant chaque release majeure