Stratégie et exécution des tests¶
Cette section constitue le plan de recette de Medusa. Elle couvre les services Docker, Discord, l'administration web, FiveM et les parcours joueurs. Elle doit évoluer avec chaque changement de comportement, même lorsqu'un test automatisé existe déjà.
Environnements requis¶
- une stack de recette construite depuis le commit à valider, avec migrations à jour ;
- une guilde Discord de test et un bot placé au-dessus des rôles administrés ;
- un compte Founder, un compte staff sans permission, un compte whitelist et un compte sans rôle ;
- deux clients FiveM connectables simultanément, dont un compte administrateur ;
- un personnage existant et un nouveau compte sans personnage ;
- un marqueur de carte, un véhicule intact, une épave et plusieurs props/MLO de test.
Ne jamais exécuter les scénarios destructifs sur la production. Utiliser des comptes, personnages, tenues, props et vestiaires identifiés comme données de recette.
Ordre conseillé¶
- Exécuter les contrôles automatisés et construire toutes les images.
- Valider la plateforme et les migrations.
- Tester l'authentification, les permissions et l'administration.
- Tester le parcours joueur, puis les outils World Edit et les commandes en jeu.
- Redémarrer la stack et rejouer les contrôles de persistance.
Contrôles automatisés¶
docker compose build
docker compose up -d
docker compose exec api alembic upgrade head
docker compose exec api pytest
docker compose exec api ruff check .
docker compose build docs
Vérifier également la syntaxe des fichiers JavaScript modifiés avec node --check. Une livraison
échoue si une commande retourne un code non nul, si MkDocs émet un avertissement en mode strict ou
si un service reste unhealthy.
Fiche d'exécution¶
Pour chaque cas, consigner : identifiant du test, commit, environnement, testeur, date, résultat
PASS/FAIL/BLOCKED, preuve (capture ou extrait de log) et anomalie associée. Les étapes marquées
« persistance » doivent être vérifiées après reconnexion ou redémarrage, pas seulement à l'écran.
Index de couverture¶
| Domaine | Cas principaux |
|---|---|
| Build, migrations, réseau, volumes, mappings, logs et documentation | PLAT-001 à PLAT-008 |
| Discord, whitelist et OAuth | AUTH-001 à AUTH-003 |
| Hiérarchie et permissions partagées | PERM-001 à PERM-003 |
| Loading screen, personnages, modération, journaux, bot et MLO | ADMIN-001 à ADMIN-006 |
| Création, spawn, recustomisation et tatouages | PLAY-001 à PLAY-005 |
| Magasins, tenue persistante et partage | CLOTH-001 à CLOTH-004 |
| Tenues en vestiaire et isolation des personnages | WARD-001 à WARD-002 |
| Inventaires, administration et concurrence | INV-001 à INV-009 |
| Panneau, terminal, véhicules, téléportation et diagnostic | GAME-001 à GAME-004 |
| Placement, magasins, vestiaires, props, streaming et interactions | WORLD-001 à WORLD-009 |
| Handling, coffres, Alt/F5, sièges et cycle de vie véhicule | AC-001 à AC-077, ADMIN-014 |
| Découverte, plans, validation humaine, implémentation et archive IA | AIWF-001 à AIWF-008 |
Critères de sortie¶
- tous les tests critiques d'accès, migrations, sauvegarde et permissions sont
PASS; - aucun crash client/serveur, erreur NUI ou exception API non expliquée ;
- aucun utilisateur ne peut exécuter une action sans sa permission ;
- les mutations importantes apparaissent dans l'audit avec le bon acteur et la bonne cible ;
- toute anomalie restante est documentée, évaluée et acceptée avant déploiement.
Pour MED-20260827-001, la clôture exige en plus la migration PostgreSQL réelle, une recette à deux
clients et la charge 48 joueurs/100 véhicules. Une suite API/Lua/Playwright verte permet le commit
de l'implémentation, mais ne remplace pas ces preuves runtime et ne suffit pas à cocher les 77 AC.
Pour MED-20260830-004, appliquer la même séparation des preuves : automatisé, PostgreSQL réel,
runtime FiveM et déploiement. La matrice AC-001 à AC-065 se trouve dans
Tests du système énergie.