852f6d5e16
**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>
150 lines
5.9 KiB
Markdown
150 lines
5.9 KiB
Markdown
# ADR-007 : Tests et Spécifications Exécutables
|
|
|
|
**Statut** : Accepté
|
|
**Date** : 2025-01-17
|
|
|
|
## Contexte
|
|
|
|
RoadWave nécessite une documentation des use cases qui soit à la fois lisible par tous les stakeholders et vérifiable automatiquement. Les scénarios utilisateurs (touriste, routier, commerçant) doivent être validés en continu.
|
|
|
|
## Décision
|
|
|
|
**Gherkin** pour les spécifications avec **Godog** comme runner de tests.
|
|
|
|
## Alternatives considérées
|
|
|
|
| Option | Lisibilité | Intégration Go | Maintenance |
|
|
|--------|------------|----------------|-------------|
|
|
| **Gherkin + Godog** | Excellente | Native | Faible |
|
|
| Gauge (Markdown) | Bonne | Plugin | Moyenne |
|
|
| Tests Go natifs | Faible (devs only) | Native | Faible |
|
|
| Concordion | Bonne | Java-centric | Élevée |
|
|
|
|
## Justification
|
|
|
|
- **Living Documentation** : Les fichiers `.feature` servent de documentation ET de tests
|
|
- **Accessibilité** : Syntaxe Given/When/Then lisible par PO, devs, testeurs
|
|
- **Cohérence stack** : Godog est le standard BDD pour Go
|
|
- **CI/CD** : Intégration simple dans les pipelines
|
|
|
|
## Structure
|
|
|
|
Les features BDD sont organisées en **3 catégories** selon la couche testée :
|
|
|
|
```
|
|
features/
|
|
├── api/ # Tests de contrats API (Backend)
|
|
│ ├── authentication/ # REST endpoints, validation email, 2FA
|
|
│ ├── recommendation/ # Algorithm backend, scoring GPS
|
|
│ ├── rgpd-compliance/ # GDPR API (delete, export, consent)
|
|
│ ├── content-creation/ # Upload, encoding, validation API
|
|
│ ├── moderation/ # Moderation workflow API
|
|
│ ├── monetisation/ # Payments, KYC, payouts API
|
|
│ ├── premium/ # Subscription API
|
|
│ ├── radio-live/ # Live streaming backend
|
|
│ └── publicites/ # Ads API, budget, metrics
|
|
│
|
|
├── ui/ # Tests d'interface utilisateur (Mobile)
|
|
│ ├── audio-guides/ # Audio player UI, modes (piéton, vélo)
|
|
│ ├── navigation/ # Steering wheel, voice commands, UI
|
|
│ ├── interest-gauges/ # Gauge visualization, progression
|
|
│ ├── mode-offline/ # Download UI, sync status
|
|
│ ├── partage/ # Share dialog
|
|
│ ├── profil/ # Creator profile screen
|
|
│ └── recherche/ # Search bar, filters UI
|
|
│
|
|
└── e2e/ # Tests end-to-end (Backend + Mobile)
|
|
├── abonnements/ # Full subscription flow (Mangopay + Zitadel + UI)
|
|
└── error-handling/ # Network errors, GPS disabled (backend + mobile)
|
|
```
|
|
|
|
### Convention de Catégorisation
|
|
|
|
#### `/features/api/` - Tests de contrats API (Backend)
|
|
|
|
**Objectif** : Tester les endpoints REST (requêtes HTTP, codes de statut, validation)
|
|
|
|
**Exécuté par** : Backend (Godog + step definitions Go dans `/backend/tests/bdd/`)
|
|
|
|
**Exemples de scénarios** :
|
|
- `POST /api/v1/auth/register` avec email invalide → retourne 400
|
|
- `GET /api/v1/contents/nearby` avec rayon 500m → retourne POI triés par distance
|
|
- `DELETE /api/v1/user/account` → supprime données RGPD conformément
|
|
|
|
**Caractéristiques** :
|
|
- Focus sur la **logique métier backend** (algorithme, validation, persistance)
|
|
- Pas d'interface utilisateur
|
|
- Testable via requêtes HTTP directes
|
|
|
|
---
|
|
|
|
#### `/features/ui/` - Tests d'interface utilisateur (Mobile)
|
|
|
|
**Objectif** : Tester les interactions utilisateur (tap, scroll, navigation, widgets)
|
|
|
|
**Exécuté par** : Mobile (Flutter `integration_test` + step definitions Dart dans `/mobile/tests/bdd/`)
|
|
|
|
**Exemples de scénarios** :
|
|
- Cliquer sur "Lecture" → widget audio player s'affiche avec progress bar
|
|
- Mode piéton activé → carte interactive affichée + bouton "Télécharger zone"
|
|
- Scroll dans liste podcasts → lazy loading déclenche pagination
|
|
|
|
**Caractéristiques** :
|
|
- Focus sur l'**expérience utilisateur mobile**
|
|
- Validation visuelle (widgets, animations, navigation)
|
|
- Mock du backend si nécessaire (tests UI isolés)
|
|
|
|
---
|
|
|
|
#### `/features/e2e/` - Tests end-to-end (Backend + Mobile)
|
|
|
|
**Objectif** : Tester les parcours complets impliquant plusieurs composants
|
|
|
|
**Exécuté par** : Backend **ET** Mobile ensemble
|
|
|
|
**Exemples de scénarios** :
|
|
- Abonnement Premium : Formulaire mobile → API Zitadel → API RoadWave → Mangopay → Confirmation UI
|
|
- Erreur réseau : Perte connexion pendant streaming → Fallback mode offline → Reprise auto après reconnexion
|
|
- Notification géolocalisée : GPS détecte POI → Backend calcule recommandation → Push notification → Ouverture app → Lecture audio
|
|
|
|
**Caractéristiques** :
|
|
- Tests **cross-composants** (intégration complète)
|
|
- Implique souvent des **services tiers** (Zitadel, Mangopay, Firebase)
|
|
- Validation du **parcours utilisateur de bout en bout**
|
|
|
|
---
|
|
|
|
### Implémentation Step Definitions
|
|
|
|
**Backend** : `/backend/tests/bdd/`
|
|
- Step definitions Go pour features `api/` et `e2e/`
|
|
- Utilise `godog` et packages backend (`service`, `repository`)
|
|
|
|
**Mobile** : `/mobile/tests/bdd/`
|
|
- Step definitions Dart pour features `ui/` et `e2e/`
|
|
- Utilise Flutter `integration_test` framework
|
|
|
|
**Note** : Les step definitions ne sont pas encore implémentées (répertoires avec `.gitkeep` seulement). Cette organisation prépare la structure pour l'implémentation future.
|
|
|
|
---
|
|
|
|
## Exemple
|
|
|
|
```gherkin
|
|
Feature: Recommandation géolocalisée
|
|
|
|
Scenario: Touriste près d'un monument
|
|
Given un utilisateur avec l'intérêt "tourisme" à 80%
|
|
And une position GPS à 100m de la Tour Eiffel
|
|
When le système calcule les recommandations
|
|
Then l'audio guide "Histoire de la Tour Eiffel" est en première position
|
|
```
|
|
|
|
## Conséquences
|
|
|
|
- Dépendance : `github.com/cucumber/godog` (MIT)
|
|
- Les use cases du README doivent être traduits en `.feature`
|
|
- CI exécute `godog run` avant chaque merge
|
|
|
|
**Librairies** : Voir [ADR-018](018-librairies-go.md) pour analyse complète des frameworks BDD
|