# 🧪 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 ! 🧪**