Files

jpgiannetti 852f6d5e16 refactor(docs): réorganiser ADR et règles métier pour clarté

**Changements majeurs** :

1. **Suppression ADR-010 (Commandes volant et likes)** :
   - Contenu consolidé dans Règle 05 (section 5.3)
   - Raison : ADR-010 était du métier déguisé en architecture
   - Section "Implémentation Technique" ajoutée à Règle 05
   - Pattern correct (addition) vs incorrect (multiplication)

2. **Déplacement ADR-011 → Compliance** :
   - `docs/adr/011-conformite-stores.md` → `docs/compliance/stores-submission.md`
   - Raison : Nature opérationnelle/légale, pas architecture technique
   - Nouveau dossier `/docs/compliance/` créé

3. **Renumérotation ADR (010-022)** :
   - Combler les trous de numérotation (010 et 011)
   - ADR-012→010, ADR-013→011, ..., ADR-024→022
   - 22 ADR numérotés en continu (001-022)
   - Historique Git préservé (git mv)

4. **Mise à jour références** :
   - Règle 03 : ADR-010 → Règle 05 (section 5.3)
   - Règle 09 : ADR-010 → Règle 05 (section 5.3)
   - INCONSISTENCIES-ANALYSIS.md : toutes références mises à jour
   - Incohérence #15 annulée (faux problème : modes séparés)

**Résultat** :
- ✅ Séparation claire ADR (technique) vs Règles métier (fonctionnel)
- ✅ Documentation compliance séparée
- ✅ Numérotation ADR continue sans trous
- ✅ Single Source of Truth (pas de redondance)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

2026-02-01 14:34:12 +01:00

3.5 KiB

Raw 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 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 (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.5 KiB Raw Blame History