Et les tests ?

La logique veut que chaque développement soit testé avant d'être mis en production. Il serait en effet délirant (et kamikaze) de fournir à vos joueurs l'accès à des fonctionnalités fraîchement codées sans avoir vérifié au préalable leur bon fonctionnement…

Le temps passé à tester une version peut parfois atteindre (voir dépasser) le temps alloué à son développement.

Parce que tester est quelque chose que personne n'apprécie, voici quelques pistes de motivation pour vous pousser à le faire systématiquement :

• un bogue en production peut corrompre les données et vous obliger à faire de la reprise de données. Souvent manuelle, cette reprise consiste tout simplement à corriger toutes les données bancales suite au bogue. Cette étape est longue et fastidieuse ;
• pire, un bogue peut vous obliger à faire un rollback, à savoir réinstaller une sauvegarde de la base de données (car vous avez totalement corrompu la base de production). Revenir à une sauvegarde est très mal perçu par les joueurs. Et pour peu que la dernière sauvegarde que vous ayez sous la main date de plusieurs semaines, vous allez probablement perdre beaucoup de joueurs ;
• vous n'êtes pas un dieu de la programmation et tout le monde crée des bogues. Mais un développeur responsable limite la casse en testant son code sous peine de passer pour un jambon ;
• les bogues de votre jeu affectent sa qualité globale et les joueurs ne resteront pas longtemps si les problèmes sont habituels ;
• corriger un bogue demande beaucoup moins de temps s'il n'est pas sur le serveur de production ;
• si vous voyez un bogue critique pendant la phase de développement vous pourrez le corriger le lendemain, mais s'il est déjà production la nuit sera courte… ;
• par respect envers vos joueurs, vous devez accepter que les tests sont de votre responsabilité, et pas de la leur. Lorsque vous avez acheté votre voiture, vous étiez quand même rassuré de savoir que les freins avaient été testés avant la commercialisation non ? ;
• vous serez beaucoup plus confiant lors de vos mises à jour si vous avez réalisé une campagne de test convenable.

Les bogues peuvent avoir des origines très variées, ils peuvent aussi bien être techniques (erreurs de syntaxe dans le code) que fonctionnels (algorithme qui fait n'importe quoi, comme un mauvais calcul). 

Le type de bogue le plus simple c'est le bogue technique : votre code est mal écrit, n'analyse pas, ne compile pas ou génère des erreurs à son exécution. Normalement ces bogues sont simples à trouver, car il suffit de tester son développement pour les remarquer, ils sautent aux yeux. Si ça finit en production, il n'y a pas d'excuse possible…

Le bogue fonctionnel est plus compliqué, car tout semble nickel d'un point de vue technique, sauf que votre algorithme ne fait pas ce qu'il est censé faire.

Enfin, une régression est une fonctionnalité qui marchait correctement, mais qui - pour diverses raisons - ne fonctionne plus suite à un développement. Parfois ce nouveau développement était sur un autre module, mais par effet de boule de neige, il a mis KO un autre module sur lequel vous ne travaillez même pas. Un peu fourbe, cette régression est difficile à remarquer pendant les développements, car on n'a pas forcément l'idée de vérifier que tout ce qui marchait fonctionne encore.

Certains bogues peuvent être liés à l'environnement (configuration du serveur, OS, serveur de base de données, etc.), mais dans un projet amateur on ne dispose en général pas des moyens pour détecter ces problèmes avant la mise en production…

Partez du principe que tout nouveau module ou tout nouveau développement doit être testé dans tous les sens. Si vous travaillez en équipe, avec un SVN par exemple, testez votre module avant de le partager au sein de l'équipe. Il s'agit d'un test unitaire, très ciblé puisque portant sur un module ou une fraction du code source bien défini. Lorsque l'on écrit un code, on sait comment il doit être utilisé et on n'a pas forcément l'idée de sortir des sentiers battus. L'utilisateur, lui, ne fera pas ce que vous attendiez, il faut donc utiliser différents comportements et vérifier que l'algorithme les prend en considération.

Par exemple si vous ajoutez un champ « taille du personnage » et que vous attendez donc que l'utilisateur saisisse une valeur numérique, vous devez gérer le cas où il entre un texte dans ce champ et lever une erreur. Ne partez surtout pas du principe que l'utilisateur fera ce qui est attendu, ou ce qui vous semble « logique » et « évident ». Vous devez anticiper et gérer les erreurs, même (et surtout) les plus improbables.

Exemples de test pour le champ « taille du personnage » (qui attend un nombre entier en centimètres) : essayer de voir comment votre code réagit lorsque l'on entre :

• "180" (cas attendu, si ça ne marche pas c'est plutôt mal barré) ;
• "" (champ vide, le classique) ;
• "1,80" (taille en mètres) ;
• "centre quatre-vingts centimètres" ;
• "1" (valeur trop basse) ;
• "999999999999999999" (valeur trop haute) ;
• ";/%µ$9_"/;" ;
• "<font color=\"red\">" ;
• "La prospérité est le lien de l'amour." (William Shakespeare) ;
• etc.

Lorsque tous les développeurs ont fini et testé leurs développements, ils sont enfin tous disponibles sur le SVN. Cette version peut normalement aller en production pour mettre à jour le jeu. Sauf que je vous conseille fortement de faire une campagne de tests de non-régression (ou « TNR »).

Il s'agit ici de vérifier que tout est consistant et fonctionnel, même les anciens bouts de code. Imaginez que l'inscription soit KO, ou bien que le module de messagerie ne fonctionne plus…

Pour cela, définissez des scénarios de test de base :

• créer un nouveau compte ;
• attaquer un autre joueur ;
• gagner un niveau ;
• créer un objet ;
• envoyer un message ;
• etc.

Ces scénarios seront à dérouler avant chaque mise en production et vous serez ainsi rassuré sur le fait que les fonctionnalités critiques sont toujours OK.

Vous pouvez également faire des tests unitaires croisés : les développeurs ciblent leurs tests sur les modules développés par les autres. Le but est de vérifier que les modules du collègue fonctionnent bien et pour cela il faut essayer de bidouiller pour voir s'il a bien pensé à traiter tous les cas possibles.

Ces tests feront également office de tests d'intégration : vérifier qu'une fois mis en commun, les développements sont toujours OK. Lorsque Bob et Maurice travaillent chacun sur leur poste, il est possible que leurs modules soient indépendamment bons, mais que lorsqu'ils se retrouvent sur le SVN, l'un des deux soit mis KO par l'autre.

Pour un projet amateur,ceci devrait permettre de pas mal limiter la casse, mais il est évidemment possible d'aller plus loin pour tout ce qui est professionnel (homologation, campagnes de recette utilisateurs, etc.). Si vous disposez de deux serveurs, vous pouvez en utiliser un pour la production, et un pour les tests. Par exemple vous pouvez installer sur le serveur de test la nouvelle version et les joueurs seront heureux de la tester pour vous. Si les tests ne remontent pas d'anomalies, vous pourrez au bout de quelque temps la mettre en production.

Il existe des méthodologies assez poussées pour les phases de tests unitaires et je vous invite fortement à chercher sur Google ce qui est préconisé (selon votre langage de développement).

J'ajouterai que dans le cadre de la création d'un jeu, c'est au créateur (ou au team leader) de veiller au bon respect de ces règles de test.

N.B. Dans le cas d'une version majeure, ces étapes de tests internes sont suivies des versions alpha et bêta (qui s'approchent des recettes utilisateurs)

Merci à DA de nous avoir permis de publier ses articles que vous pouvez retrouver sur son blog.

Merci à ClaudeLELOUP pour sa relecture orthographique.