veza/docs/archive/root-md/TESTS_MVP_README.md

440 lines
11 KiB
Markdown
Raw Normal View History

# 🧪 Tests Exhaustifs Intégration Veza MVP
> **Suite de tests complète pour valider que l'application Veza est prête pour le MVP**
Cette documentation décrit comment exécuter les tests exhaustifs d'intégration pour valider toutes les fonctionnalités de l'application Veza MVP.
---
## 📋 Table des Matières
1. [Vue d'ensemble](#vue-densemble)
2. [Prérequis](#prérequis)
3. [Setup Environnement](#setup-environnement)
4. [Tests API (curl)](#tests-api-curl)
5. [Tests E2E (Playwright)](#tests-e2e-playwright)
6. [Rapport de Bugs](#rapport-de-bugs)
7. [Troubleshooting](#troubleshooting)
---
## 🎯 Vue d'ensemble
Cette suite de tests couvre **TOUTES** les fonctionnalités critiques du MVP :
### ✅ Fonctionnalités Testées
- **Authentification** : Register, Login, Logout, Refresh Token, Route Guards
- **Gestion Utilisateur** : Profil, Mise à jour, Recherche
- **Tracks** : Liste, Upload, Détails, Recherche, Suppression
- **Playlists** : CRUD complet, Ajout de tracks
- **Sessions** : Liste, Stats, Révocation
- **Navigation & UX** : Dashboard, Navigation, Responsive Design
- **Gestion d'Erreurs** : 404, Network errors, Validation API
### 📂 Structure des Tests
```
veza/
├── scripts/
│ ├── setup-mvp-test-env.sh # Setup environnement
│ ├── test-mvp-api.sh # Tests API avec curl
│ └── generate-bug-report.sh # Générateur rapport bugs
└── apps/web/e2e/
└── mvp-integration.spec.ts # Tests E2E Playwright
```
---
## 🔧 Prérequis
### Commandes Requises
- `curl` - Tests API
- `jq` - Parsing JSON (optionnel mais recommandé)
- `node` & `npm` - Tests frontend
- `go` - Backend (pour vérification)
### Services à Démarrer
1. **Backend Go** sur `http://localhost:8080`
2. **Frontend React** sur `http://localhost:5173` ou `http://localhost:3000`
3. **PostgreSQL** (pour le backend)
4. **Redis** (optionnel, pour le backend)
---
## 🚀 Setup Environnement
### Option 1 : Script Automatique
```bash
./scripts/setup-mvp-test-env.sh
```
Ce script :
- ✅ Vérifie que toutes les commandes sont installées
- ✅ Vérifie que les services sont running
- ✅ Configure les variables d'environnement
- ✅ Donne des instructions si quelque chose manque
### Option 2 : Setup Manuel
#### 1. Démarrer le Backend
```bash
cd veza-backend-api
# Vérifier que PostgreSQL et Redis sont running
docker-compose up -d postgres redis # si docker-compose existe
# OU vérifier que les services sont accessibles
go run cmd/api/main.go
# OU
go run cmd/server/main.go
```
#### 2. Démarrer le Frontend
```bash
cd apps/web
npm install
npm run dev
```
#### 3. Vérifier que les services répondent
```bash
# Backend health check
curl -v http://localhost:8080/health
curl -v http://localhost:8080/api/v1/health
# Frontend
curl -v http://localhost:5173
# OU
curl -v http://localhost:3000
```
#### 4. Configurer les variables d'environnement
```bash
export API_URL="http://localhost:8080/api/v1"
export FRONTEND_URL="http://localhost:5173"
export TEST_EMAIL="test-$(date +%s)@example.com"
export TEST_PASSWORD="TestPassword123!"
export TEST_USERNAME="testuser_$(date +%s)"
```
---
## 🧪 Tests API (curl)
Les tests API utilisent `curl` pour tester directement les endpoints backend.
### Exécuter tous les tests API
```bash
./scripts/test-mvp-api.sh
```
### Tests Inclus
#### Phase 1 : Authentification
- ✅ AUTH-001: Page de Login accessible
- ✅ AUTH-002: Page de Register accessible
- ✅ AUTH-003: Inscription nouvel utilisateur
- ✅ AUTH-004: Login avec nouvel utilisateur
- ✅ AUTH-005: Accès route protégée avec token
- ✅ AUTH-006: Accès route protégée SANS token (401)
- ✅ AUTH-007: Refresh token
- ✅ AUTH-008: Logout
- ✅ AUTH-009: Login avec mauvais mot de passe (401)
- ✅ AUTH-010: Check username disponibilité
#### Phase 2 : Utilisateur/Profil
- ✅ USER-001: Voir son profil
- ✅ USER-002: Mettre à jour son profil
- ✅ USER-003: Recherche utilisateurs
- ✅ USER-004: Ne peut pas modifier le profil d'un autre (403)
#### Phase 3 : Tracks
- ✅ TRACK-001: Lister les tracks
- ✅ TRACK-002: Upload un track (simulé)
- ✅ TRACK-003: Voir un track spécifique
- ✅ TRACK-005: Recherche de tracks
#### Phase 4 : Playlists
- ✅ PLAYLIST-001: Créer une playlist
- ✅ PLAYLIST-002: Lister ses playlists
- ✅ PLAYLIST-003: Voir une playlist
- ✅ PLAYLIST-004: Mettre à jour une playlist
- ✅ PLAYLIST-005: Ajouter un track à la playlist
- ✅ PLAYLIST-006: Recherche de playlists
- ✅ PLAYLIST-007: Supprimer une playlist
#### Phase 5 : Sessions
- ✅ SESSION-001: Lister ses sessions
- ✅ SESSION-002: Stats sessions
- ✅ SESSION-003: Révoquer une session spécifique
### Sortie du Script
Le script affiche :
- ✅ Tests passés (vert)
- ❌ Tests échoués (rouge)
- ⚠️ Warnings (jaune)
- 📊 Rapport final avec statistiques
Exemple de sortie :
```
============================================================================
RAPPORT FINAL
============================================================================
Tests passés: 25
Tests échoués: 2
Total: 27
[✗] Certains tests ont échoué
```
---
## 🎭 Tests E2E (Playwright)
Les tests E2E utilisent Playwright pour tester l'application comme un utilisateur réel.
### Exécuter tous les tests E2E
```bash
cd apps/web
npm run test:e2e -- e2e/mvp-integration.spec.ts
```
### Exécuter un test spécifique
```bash
# Test d'authentification uniquement
npx playwright test e2e/mvp-integration.spec.ts -g "Authentication"
# Test de navigation uniquement
npx playwright test e2e/mvp-integration.spec.ts -g "Dashboard"
# Test en mode headed (voir le navigateur)
npx playwright test e2e/mvp-integration.spec.ts --headed
# Test avec UI (debug interactif)
npx playwright test e2e/mvp-integration.spec.ts --ui
```
### Tests Inclus
#### 1. Authentication Flow
- ✅ 1.1: Login page loads correctly
- ✅ 1.2: Register page loads correctly
- ✅ 1.3: Can register new user
- ✅ 1.4: Can login with registered user
- ✅ 1.5: Protected route redirects when not logged in
- ✅ 1.6: Can logout
#### 2. Dashboard & Navigation
- ✅ 2.1: Dashboard loads without errors
- ✅ 2.2: Navigation works
#### 3. Tracks Management
- ✅ 3.1: Tracks page loads
- ✅ 3.2: Upload track button exists
#### 4. Playlists Management
- ✅ 4.1: Playlists page loads
- ✅ 4.2: Can create playlist
#### 5. Profile Management
- ✅ 5.1: Profile page loads
- ✅ 5.2: Can update profile
#### 6. API Response Validation
- ✅ 6.1: API returns correct response format
- ✅ 6.2: User ID is string UUID
- ✅ 6.3: Error responses have correct format
#### 7. Error Handling
- ✅ 7.1: 404 page exists
- ✅ 7.2: Network error handling
#### 8. Responsive Design
- ✅ 8.1: Mobile viewport (375x667)
- ✅ 8.2: Tablet viewport (768x1024)
- ✅ 8.3: Desktop viewport (1920x1080)
### Générer un Rapport HTML
```bash
npx playwright test e2e/mvp-integration.spec.ts --reporter=html
npx playwright show-report
```
---
## 🐛 Rapport de Bugs
### Générer un Rapport de Bugs
```bash
./scripts/generate-bug-report.sh [output-file.json]
```
Le rapport est au format JSON et contient :
- ID du bug
- Titre et description
- Sévérité (critical, high, medium, low)
- Catégorie (auth, tracks, playlists, etc.)
- Steps to reproduce
- Expected vs Actual behavior
- Statut (open, fixed, etc.)
### Exemple de Rapport
```json
{
"report_date": "2025-01-27T10:30:00Z",
"test_suite": "MVP Integration Tests",
"bugs": [
{
"id": "BUG-001",
"title": "Login fails with valid credentials",
"description": "User cannot login even with correct email and password",
"severity": "critical",
"category": "auth",
"steps_to_reproduce": "1. Go to /login 2. Enter valid credentials 3. Click submit",
"expected_behavior": "User should be redirected to dashboard",
"actual_behavior": "Error message appears: 'Invalid credentials'",
"status": "open",
"created_at": "2025-01-27T10:30:00Z"
}
],
"summary": {
"total_bugs": 1,
"critical": 1,
"high": 0,
"medium": 0,
"low": 0
}
}
```
### Ajouter un Bug Manuellement
```bash
./scripts/generate-bug-report.sh report.json "BUG-001" "Title" "Description" "critical" "auth" "Steps" "Expected" "Actual"
```
---
## 🔍 Troubleshooting
### Problème : Backend ne répond pas
```bash
# Vérifier que le backend est running
curl http://localhost:8080/health
# Vérifier les logs
cd veza-backend-api
# Vérifier les logs du processus Go
```
### Problème : Frontend ne répond pas
```bash
# Vérifier que le frontend est running
curl http://localhost:5173
# Vérifier les logs
cd apps/web
npm run dev
# Vérifier les erreurs dans la console
```
### Problème : Tests API échouent avec 401
- Vérifier que l'utilisateur de test est bien créé
- Vérifier que le token est valide
- Vérifier que le backend accepte les tokens JWT
### Problème : Tests E2E échouent avec timeout
- Augmenter le timeout dans `playwright.config.ts`
- Vérifier que le frontend répond rapidement
- Vérifier les erreurs console dans Playwright
### Problème : Rate Limiting (429)
Le backend a un rate limiter. Si vous obtenez des erreurs 429 :
- Attendre quelques secondes entre les requêtes
- Réduire le nombre de workers dans Playwright (déjà configuré à 1)
- Désactiver le rate limiter en développement
### Problème : Tests flaky (parfois passent, parfois échouent)
- Vérifier la stabilité du backend
- Vérifier les timeouts
- Vérifier les conditions de course (race conditions)
- Utiliser `--retries` dans Playwright
---
## 📊 Checklist de Validation MVP
Avant de considérer le MVP comme prêt, vérifier que :
- [ ] Tous les tests API passent (100%)
- [ ] Tous les tests E2E passent (100%)
- [ ] Aucun bug critical dans le rapport
- [ ] Les fonctionnalités principales fonctionnent :
- [ ] Inscription/Login
- [ ] Upload de tracks
- [ ] Création de playlists
- [ ] Navigation fluide
- [ ] Responsive design
- [ ] Performance acceptable (< 2s pour les pages principales)
- [ ] Pas d'erreurs console critiques
- [ ] Pas d'erreurs réseau (404, 500, etc.)
---
## 📝 Notes
- Les tests créent des utilisateurs de test avec des emails uniques (timestamp)
- Les données de test sont nettoyées automatiquement (ou manuellement si nécessaire)
- Les tests sont conçus pour être idempotents (peuvent être exécutés plusieurs fois)
---
## 🚀 Prochaines Étapes
Après avoir exécuté tous les tests :
1. **Analyser le rapport de bugs** : Identifier les problèmes critiques
2. **Corriger les bugs** : Prioriser par sévérité
3. **Ré-exécuter les tests** : Valider les corrections
4. **Documenter les changements** : Mettre à jour la documentation
5. **Préparer le déploiement** : Une fois tous les tests passent
---
## 📞 Support
Pour toute question ou problème :
1. Vérifier cette documentation
2. Vérifier les logs des tests
3. Vérifier les issues GitHub existantes
4. Créer une nouvelle issue si nécessaire
---
**Bon testing ! 🧪**