Stratégie de test pour les jeux

J'ai hérité d'un jeu éducatif basé sur le Web. Au cours de la dernière année, j'ai travaillé à stabiliser le code et à ajouter de nouvelles fonctionnalités. La plupart de la logique se trouve dans le front-end, donc les tests unitaires back-end, bien qu'utiles, couvrent un petit pourcentage du code.

Le jeu est arrivé au point où il commence à devenir complexe. Il existe deux modes différents pour chaque jeu et le jeu se comporte différemment selon le mode. Il existe également divers drapeaux qui affectent le jeu.

Je suis développeur d'applications depuis plus de 10 ans maintenant et cela me laisse perplexe. Dans le monde de l'entreprise, un algorithme fonctionne toujours de la même manière. J'écrirai un test unitaire pour un algorithme, je m'attendrai à la valeur 42 et ce sera une erreur si je n'obtiens pas cette valeur.

En ce qui concerne les jeux, je suis perdu. Comment les tester? J'ai des testeurs à ma disposition. Je peux passer du temps à écrire des tests unitaires.

Les testeurs sont ... peu fiables. Ils ne sont pas les meilleurs pour éliminer les problèmes et je ne leur ai pas donné la meilleure direction. À moins de passer une tonne de temps à chaque cycle de sortie pour tester chaque permutation et combinaison du jeu, comment dois-je les utiliser comme ressource?

Les tests unitaires semblent limités. Étant donné que la plupart de la logique est javascript (et j'ai hérité du code spaghetti), je peux utiliser une suite frontale comme Cucumber ou sélénium pour garantir que certaines fonctionnalités fonctionnent.

Est-ce la meilleure stratégie? Comment les sociétés de jeux testent-elles les jeux?

J'ai lu la question " Développement piloté par les tests pour les jeux complexes " (entre autres sur le site), mais elle ne répond pas à ce que je recherche. Je demande des stratégies, pas des exemples spécifiques de tests.

Dans le monde de l'entreprise, un algorithme fonctionne toujours de la même manière. J'écrirai un test unitaire pour un algorithme, je m'attendrai à la valeur 42 et ce sera une erreur si je n'obtiens pas cette valeur.

Ce n'est pas très différent dans les jeux. La présence de deux modes et de plusieurs indicateurs dans le jeu sur lequel vous travaillez ne change rien: si vous prenez un mode spécifique avec un ensemble spécifique d'indicateurs, vous obtiendrez toujours la même valeur encore et encore lorsque vous testerez une partie de le code source.

Avec trop de modes et de drapeaux, le jeu peut rapidement devenir très difficile à tester, en raison du nombre de variantes possibles. Afin d'atténuer le risque de rencontrer cette difficulté tôt, vous devez:

• Mock / stub sévèrement . Gardez les pièces testées petites et raillez tout ce sur quoi elles comptent.

  S'ils s'appuient sur le temps, moquez l'objet temps pour toujours donner un résultat spécifique ou un ensemble de résultats spécifiques, indépendamment du temps réel.

  S'ils s'appuient sur random(), se moquer de lui pour fournir une constante à chaque fois.

• Refactor . Si les tests commencent à être trop compliqués ou si vous voyez qu'une classe, pour être testée, nécessite douze arguments après avoir implémenté l'injection de dépendance, alors qu'elle n'en demandait que deux auparavant, vous devez refactoriser le code.

• Remettez en question les règles commerciales réelles de l'application. J'ai arrêté de compter le nombre de projets qui étaient presque impossibles à tester en raison du nombre de variations différentes requises par les exigences fonctionnelles dont personne n'avait besoin ni compris - pas même les parties prenantes.

  Lorsqu'un petit site Web de commerce électronique a besoin de dix pages pour expliquer les exigences fonctionnelles utilisées pour déterminer comment les prix des expéditions sont calculés, il ne faut pas commencer par écrire des tests ou du code, mais au lieu de cela, revenir aux parties prenantes et travailler avec elles pour produire exigences raisonnables .

Enfin, automatisez chaque test . Les testeurs sont nécessaires pour découvrir les situations où l'application échoue. Utiliser des testeurs pour exécuter, encore et encore, la même action à chaque révision est contre-productif et irrespectueux des testeurs: les tests de régression doivent être effectués par des machines, pas par des personnes. Les gens, en revanche, sont beaucoup mieux à même de trouver d'éventuels bugs. "Et si je ..." est l'une des techniques qu'ils peuvent utiliser ("Et si j'entre quelques mégaoctets de données binaires contenant plusieurs \ x00 dans un champ qui demande mon âge, et voir ce qui se passera?"), mais des approches plus formelles peuvent également être utilisées.