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

🧪 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
2. Prérequis
3. Setup Environnement
4. Tests API (curl)
5. Tests E2E (Playwright)
6. Rapport de Bugs
7. 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

./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

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

cd apps/web
npm install
npm run dev

3. Vérifier que les services répondent

# 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

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

./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

cd apps/web
npm run test:e2e -- e2e/mvp-integration.spec.ts

Exécuter un test spécifique

# 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

npx playwright test e2e/mvp-integration.spec.ts --reporter=html
npx playwright show-report

---

🐛 Rapport de Bugs

Générer un Rapport de Bugs

./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

{
  "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

./scripts/generate-bug-report.sh report.json "BUG-001" "Title" "Description" "critical" "auth" "Steps" "Expected" "Actual"

---

🔍 Troubleshooting

Problème : Backend ne répond pas

# 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

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