# 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](../../README.md) traduits en `.feature`
- **Exécution** : Avant release
- **Détails** : Voir [ADR-007](007-tests-bdd.md) 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