Tester et debugger du code temps réel

Trouver et corriger des bugs qui n'apparaissent que quand deux joueurs interagissent

⏱ Estim. ~10 min

01 · Lire

Ton jeu marche pour le happy path — deux joueurs se trouvent, jouent chacun leur tour, quelqu'un gagne. Mais le code multijoueur temps réel a toute une catégorie de bugs que tu n'as jamais rencontrés.

Ces bugs sont liés au timing. Ils n'apparaissent que quand des événements arrivent dans un ordre précis, ou quand des joueurs font des trucs imprévus comme fermer le navigateur en pleine partie. Ils restent invisibles aux tests normaux parce que tu joues « bien ». Un bon dev teste aussi les scénarios moches.

Points clés

Les bugs temps réel sont liés au timing — ils n'apparaissent pas dans les tests normaux
Les scénarios de déconnexion sont la source la plus fréquente de bugs
Chrome DevTools a un inspecteur WebSocket pour debugger
Teste les scénarios moches, pas seulement le happy path

02 · Étape par étape

Utilise Chrome DevTools pour inspecter le trafic WebSocket. C'est comme ça que tu debug les problèmes de communication temps réel.

1. Ouvrir DevTools

Clic droit n'importe où sur la page du jeu et sélectionne 'Inspect', ou appuie sur F12. Clique sur l'onglet 'Network' en haut de DevTools.

2. Filtrer WebSocket

Dans l'onglet Network, clique sur le bouton de filtre 'WS' (abréviation de WebSocket). Ça masque toutes les requêtes HTTP normales et n'affiche que les connexions WebSocket.

3. Trouver la connexion Socket.io

Recharge la page. Tu vas voir une connexion WebSocket apparaître — clique dessus. Puis clique sur l'onglet 'Messages'. Ça affiche en temps réel chaque message envoyé et reçu.

4. Observer le flux d'événements

Joue au jeu et regarde l'onglet Messages. Tu verras des choses comme 'find-game' qui part (flèche verte) et 'game-start' qui arrive (flèche rouge). Chaque message affiche le nom de l'événement et le payload de données. C'est l'outil ultime pour debugger Socket.io.

03 · Pratique réelle

Ouvre l'inspecteur WebSocket et confirme que tu vois bien le flux d'événements.

04 · Liste de vérification

Teste ces 8 cas limites. Ouvre deux onglets et essaie chaque scénario. Si quelque chose casse, tu as trouvé un bug à corriger.

Un joueur ferme son onglet de navigateur pendant qu'il attend dans la file de matchmaking — le serveur nettoie-t-il ?
Un joueur ferme son onglet en pleine partie — l'adversaire voit-il 'Opponent disconnected' ?
Un joueur clique sur une case déjà occupée — rien ne se passe ?
Un joueur clique une case quand ce n'est pas son tour — rien ne se passe ?
Un joueur clique rapidement sur plusieurs cases — seul le premier coup valide est enregistré ?
Une partie est gagnée et terminée — les clics suivants sur le plateau sont-ils ignorés ?
Un joueur clique 'Play Again' après une partie — le matchmaking redémarre-t-il proprement ?
Trois onglets ouverts : deux en partie, un qui clique 'Find Game' — le troisième joueur attend-il correctement ?

05 · Modèle de prompt

Que tu aies trouvé des bugs ou pas, demande à Claude de reviewer ton code pour repérer les problèmes temps réel classiques.

Aide-moi à reviewer le code du tic-tac-toe pour trouver bugs et cas limites. Regarde server.js, game.js, matchmaking.js et public/client.js. Concentre-toi sur : (1) Race conditions — que se passe-t-il si deux événements arrivent en même temps ? (2) Memory leaks — les joueurs déconnectés sont-ils bien retirés de toutes les structures de données ? (3) Incohérences d'état — le client et le serveur peuvent-ils se désynchroniser ? (4) Validations manquantes — un joueur peut-il envoyer un move pour une partie où il n'est pas ? Liste les problèmes que tu trouves, puis corrige-les.

06 · Lire

Debugger du code temps réel, c'est une compétence. Quand quelque chose tourne mal, ton premier outil c'est console.log côté serveur — ajoute des log avant et après chaque handler d'événement. Ton deuxième outil, c'est l'inspecteur WebSocket du navigateur. Ton troisième outil, c'est demander à Claude de tracer un scénario.

La plupart des bugs temps réel tombent dans trois catégories :

1. Références obsolètes — un joueur se déconnecte mais son socket est encore référencé quelque part 2. Nettoyage manquant — la partie se termine mais les données de la room ne sont pas supprimées 3. Race conditions — deux événements arrivent dans un ordre que tu n'avais pas prévu

Si ton jeu passe les 8 tests de cas limites ci-dessus, il est solide. Sinon, tu sais maintenant exactement où regarder.

Points clés

console.log côté serveur, c'est ton premier outil de debug
L'inspecteur WebSocket de DevTools, c'est ton deuxième
La plupart des bugs viennent de références obsolètes, de nettoyage manquant, de race conditions
Quand tu es coincé, demande à Claude de tracer le scénario

07 · Quiz

Un joueur se déconnecte en pleine partie mais le serveur ne nettoie pas ses données. Que se passe-t-il quand le prochain joueur arrive ?

Le nouveau joueur peut être apparié au fantôme du joueur déconnecté, ce qui crée une partie cassée
Rien — le serveur s'en occupe tout seul
Socket.io retire automatiquement toutes les données du socket déconnecté
Le navigateur va reconnecter le joueur déconnecté

Autres leçons de ce chapitre

⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.

※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.