Tests du temps et de la météo¶
TWR-001 — Échelles de temps¶
Prérequis : un admin avec lecture et un autre avec édition du temps.
- Sélectionner le temps GTA et mesurer l'avancée pendant deux minutes réelles.
- Sélectionner le temps réel avec
+180, puis-180, autour d'un changement de journée. - Reconnecter un joueur et redémarrer la ressource.
Attendu : le GTA avance à environ ×30 sans saut lors des synchronisations ; le temps réel suit
Europe/Paris, +180 avance bien l'horloge, et tous les joueurs voient la même heure.
TWR-002 — Génération sur sept jours¶
Prérequis : base sans créneaux météo.
- Démarrer l'API et compter les créneaux.
- Avancer l'heure de référence et relancer la maintenance.
- Inspecter une période humide puis sèche.
Attendu : au moins 168 heures glissantes sont disponibles, les heures passées disparaissent, les nouvelles sont déterministes et les tendances saisonnières diffèrent sans dépendance Internet.
TWR-003 — Édition et transitions¶
Prérequis : planning généré et droits d'édition météo.
- Tenter de modifier l'heure courante depuis les deux admins.
- Tenter
CLEAR → THUNDER, puis une chaîneCLOUDS → OVERCAST → RAIN. - Observer le passage horaire pendant les dix premières minutes et après la dixième.
- Ouvrir un créneau dans les deux administrations et inspecter les choix proposés.
Attendu : le courant et les ruptures sont refusés ; les chaînes valides persistent et sont diffusées ; la transition est progressive pendant dix minutes puis la cible reste stable. Les sélecteurs ne proposent que les états compatibles avec les deux heures voisines. Une valeur acceptée reste affichée après actualisation ; un conflit concurrent affiche son erreur sans l'effacer lors du rechargement.
TWR-004 — Permissions et concurrence¶
Prérequis : comptes possédant séparément les trois permissions.
- Consulter, modifier l'horloge et modifier un créneau avec chaque profil.
- Forger les appels web et internes sans permission.
- Modifier simultanément deux créneaux voisins.
Attendu : chaque action exige son droit précis, les mutations sont auditées et la validation du graphe empêche que la concurrence laisse une séquence météorologique invalide.
TWR-005 — Calendrier des prévisions¶
Prérequis : planning généré, administrations web et en jeu accessibles avec un compte ayant
ADMIN_ALLOW_VIEW_TIME_WEATHER et ADMIN_ALLOW_EDIT_WEATHER_SCHEDULE.
- Ouvrir la météo dans chaque administration avant puis après un changement de journée.
- Contrôler les en-têtes, les 24 lignes horaires et le nombre de colonnes.
- Essayer une heure passée, l'heure courante et une heure future compatible.
- Réduire la largeur de la fenêtre web et tester le défilement horizontal dans la NUI.
- Vérifier le créneau contenant l'heure serveur, puis actualiser après un changement d'heure.
Attendu : exactement sept colonnes apparaissent, du jour serveur courant à J+6, avec les dates
et heures interprétées dans Europe/Paris. Les cellules absentes, passées ou courantes sont
verrouillées ; une heure future autorisée se modifie et reste synchronisée dans les deux interfaces.
Un unique créneau porte la mention ACTIF, un contour turquoise distinct et l'attribut
aria-current="time" ; le marquage passe au nouveau créneau au changement d'heure.
TWR-006 — Propagation des changements¶
Prérequis : deux joueurs connectés, un admin web et un admin en jeu autorisés à modifier le temps et les prévisions.
- Modifier le mode et le décalage horaire depuis le web, puis chronométrer l'effet sur les clients.
- Répéter depuis F10 et vérifier le message de confirmation dans le terminal admin.
- Modifier un créneau météo futur depuis chaque interface, recharger l'autre interface, puis attendre le début de ce créneau.
- Redémarrer
medusa-time-weatheret reconnecter un joueur.
Attendu : une modification web est diffusée en cinq secondes au maximum ; une modification F10 est diffusée avant sa confirmation. L'heure change immédiatement après réception. La météo future persiste et prend effet uniquement à son heure planifiée, avec le même résultat pour tous les joueurs.
TWR-007 — Date client sans bibliothèque os¶
Prérequis : medusa-time-weather et medusa-hud démarrés sur un client FiveM standard.
- Utiliser le mode temps réel avant et après minuit, puis appliquer un décalage franchissant la date.
- Contrôler un 29 février d'année bissextile et le premier jour d'un mois.
- Observer F8 et comparer la date, le jour de semaine et l'heure affichés avec l'état serveur.
Attendu : aucune erreur liée à os n'apparaît. Le HUD affiche la date grégorienne et le bon jour
de semaine, y compris aux changements de jour, de mois et d'année ; l'horloge continue à évoluer.
TWR-008 — Cache pendant panne API¶
Avec un état déjà diffusé, couper l'API pendant plusieurs polls puis la restaurer après modification du planning.
Attendu : les clients conservent le dernier état valide, aucune requête ne se chevauche, un seul log de panne puis un seul log de rétablissement apparaissent, et le nouvel état est diffusé au retour.