Quelle est la fréquence des tests automatisés dans le développement de jeux? [fermé]

Les développeurs de jeux utilisent-ils pour écrire des tests unitaires et d’intégration? Quelle est la fréquence parmi les développeurs de puzzle? Et parmi les développeurs de MMORPG et FPS?

(Je n’ai aucune formation en développement de jeux et je n’envisage pas de travailler avec cela - c’est un doute qui m’est venu à l’esprit. Donc, inutile d’essayer de me convaincre de les écrire, même parce que j’aime déjà écrire des tests automatisés. )

En général, les tests unitaires et d'intégration de jeux ne sont pas si courants. Ceci est principalement dû au fait que l'aspect rendu des jeux est généralement étroitement lié au reste de la mécanique du jeu. Il peut donc être très difficile d'écrire réellement des tests unitaires qui fonctionnent.

Cela dit, les tests unitaires peuvent se produire dans le développement de jeux et si le code est configuré pour cela, cela peut être très bénéfique. Cependant, il peut être beaucoup plus courant d'écrire des tests automatisés pour les jeux, généralement sous la forme d'un programme d'intelligence artificielle capable de jouer efficacement le jeu à une vitesse supérieure à celle d'un joueur normal. Il y a d'excellentes histoires de développeurs qui font exactement cela dans cette question sur les tests automatisés . Ce type de test automatisé est potentiellement meilleur, car le test unitaire peut ne pas détecter un bogue dans le moteur de rendu, mais un test automatisé est plus susceptible d'exposer un tel problème.

En fin de compte, tout dépend du studio. Certains studios procéderont à une sorte de test automatisé, tandis que d'autres pourraient simplement engager 20 lycéens cet été pour jouer à leur jeu pendant des heures.

D'après mon expérience, ce n'est pas très courant.

La plupart du temps, les tests unitaires ne se produisent pas car la plupart des développeurs de jeux sont issus d'une époque et d'une culture antérieures à la généralisation de ce type. Il est donc difficile de soutenir que de telles méthodes sont nécessaires. Cela est devenu encore plus vrai au cours des dernières années, l’espoir étant que l’utilisateur soit en mesure de corriger son propre logiciel après sa publication.

C'est en partie parce que le langage dominant dans l'industrie du développement de jeux est le C ++, ce qui rend les tests unitaires un peu plus lourds que d'autres langages. Les frameworks de tests unitaires existent, mais ils ne sont pas aussi faciles à utiliser que des systèmes similaires dans des langages plus modernes qui peuvent utiliser la réflexion et des astuces similaires pour accélérer la détection des cas de test.

En outre, c’est parce que les jeux ne se prêtent généralement pas aux tests unitaires - une grande partie de la logique dépend de sources semi-déterministes (matériel graphique, cadencements d’entrée, fréquence de trame, par exemple); graphiques à l’écran, effets sonores) et certains n’ont presque aucune signification en dehors du contexte de jeu complet (par exemple, IA réactive complexe, simulations physiques). Il existe des exceptions - beaucoup, si vous travaillez dur pour créer le code de cette façon - mais dans l'ensemble, les tests coûtent plus cher dans les jeux que dans la plupart des autres types de logiciels et le rapport coût / bénéfice est donc plus discutable.

En ce qui concerne les tests d'intégration, je n'ai jamais entendu parler de ce terme explicitement utilisé dans le développement de jeux, mais de nombreux développeurs effectuent des tests automatisés de l'ensemble du système, dans la mesure du possible. En un sens, je dirais peut-être qu'un développeur professionnel sur trois le fait, car il n'est pas toujours facile à configurer et parce que les avantages sont réduits du fait que pratiquement tous les développeurs de moyenne à grande taille (ou leur éditeur) ont une assurance qualité. département qui effectuera manuellement des tests similaires. L’assurance-qualité est généralement beaucoup moins payée que les développeurs; il peut donc être considéré comme économique de leur laisser les tests, plutôt que d’y investir du temps de code supplémentaire. (Controversé.)

Je ne vois pas en quoi l'écriture d'un jeu est différente de tout autre logiciel en ce qui concerne les tests. Chaque composant du logiciel, qu'il s'agisse de déclencher un événement programmé, d'envoyer des commandes à un personnage du jeu ou d'appuyer sur les boutons du menu, doit être testé pour une exécution correcte.

Tester s'il est possible de terminer le jeu est une autre affaire et ne relève pas tellement des tests unitaires ou d'intégration.

En général, l'automatisation des tests d'interface utilisateur (même dans les programmes classiques) est plus difficile que l'automatisation classique. Ainsi, même si vous pouvez écrire des tests unitaires pour vos jeux, tester le jeu réel est plus difficile. La plupart des entreprises utilisent des testeurs humains qui gèrent le jeu de temps et encore.

Par exemple, voici un article expliquant comment cela se passe dans un petit Game Studio (2 développeurs). D'après ce que j'ai lu, il semble que leur validation n'est pas très détaillée (l'automatisation démarre le jeu et enregistre les erreurs / les assertions).

Cependant, certaines entreprises ont très bien réussi avec la semi-automatisation (telle que Microsoft Test Studios). C'est-à-dire que les développeurs ou les SDET construisent des outils qui facilitent considérablement les tests du jeu. Il y a eu des discussions sur le Gamefest où ils ont expliqué comment ils avaient testé Crackdown, par exemple, ou Fable. Par exemple, ils utilisent toujours des testeurs qui vérifient que chaque objet est là où ils sont supposés se trouver, mais ils utilisent un outil qui prend un instantané de cet emplacement, de sorte que tout ce que l’utilisateur fait est de vérifier visuellement qu’il est là sans avoir à jouer au jeu.

Voici un bon exposé sur le type d’outils qu’ils construisent / utilisent pour tester les jeux. Il s’agit de "Test Lead Gems: Devancer face à la complexité croissante de nos jeux"

Je parierais que le code de serveur MMO et multijoueur est cependant un peu plus souvent testé.

À tout le moins, les tests de régression automatisés sont courants. Je les ai vus implémentés sous forme de contrôles de masse complets lors du démarrage du serveur, par exemple pour s'assurer qu'un nouveau serveur "cloud" était configuré correctement avant qu'il ne commence à accepter les lecteurs; une suite de régression assez bonne construite sur 3-4 ans, dans ce cas, a fonctionné en environ 4 secondes, alors que mettre en place un hôte virtuel (à partir d’une image vierge du système d’exploitation) prenait presque 10 minutes, il en valait donc la peine. Nous avons effectué les mêmes tests sur un «système de construction continuelle» de notre référentiel Subversion afin de rechercher des erreurs gênantes et assez courantes qui se reproduisaient. créer des doublons d'objets au fur et à mesure de leur transmission: instanciation, mise en cache, et le code de passage sur le réseau était couvert à près de 100%; nous avons continué à penser que nous avions pensé à tout ce qui pouvait être testé, puis nous avons découvert un nouveau cas «amusant».

Sur plusieurs MMO sur lesquels j'ai travaillé, nous développions également des "clients de stub" pour effectuer des tests unitaires initiaux, et fournissions généralement des commandes "opérateur" pour effectuer des tests unitaires ad-hoc de nouvelles fonctionnalités. Cela nous a permis d’exécuter le code serveur avant que le client ne soit prêt à en tirer parti, et d’exercer des situations "impossibles" (par exemple, téléporter un joueur à l’intérieur d’un mur) pour garantir le bon fonctionnement des gestionnaires de récupération d’erreur. La mise en ligne d'une nouvelle fonctionnalité sur le serveur peut parfois prendre plusieurs jours de moins que l'assistance du client. à l'inverse, nous devrions parfois créer une méthode de serveur «factice» pour le client, renvoyant des données fausses mais bien formées, si elles nous précèdent.

Cependant, le développement de MMO en général est sujet à beaucoup plus de ce type de problèmes, ce qui pourrait refléter l'environnement. Lorsque je travaillais sur des systèmes de jeu intégrés, les «tests» étaient pratiquement inouïs pour tout sauf un code de widget réutilisable (par exemple des éditeurs de texte).

Une autre raison pour laquelle les tests automatisés ne sont pas si courants dans le développement de jeux que l’on puisse envisager est que, pour la plupart des jeux, de nombreux volontaires de tests bêta sont convaincus que la participation à la bêta de jeux est un «avantage» lors de la sortie du jeu. Les tests automatisés sont bien entendu issus d'exigences de qualité, mais également de contraintes budgétaires. C’est pourquoi, dans le domaine des jeux, de nombreux testeurs expérimentés sont prêts à effectuer des tests gratuits. C’est peut-être une autre raison pour laquelle les tests automatisés ne sont pas si répandus.

J'ai participé à une table ronde sur les tests automatisés à la GDC 2011 . IIRC, il y avait environ 60 personnes dans la salle. À un moment donné, le modérateur a mené une enquête sur la couverture des tests unitaires. Une personne a déclaré avoir une couverture de code supérieure à 90%. Tout le monde se moquait de l'idée d'atteindre jamais 1% de couverture. Si ce groupe est une représentation juste de l’ensemble du secteur, je dirais que les tests automatisés ne se produisent généralement pas beaucoup, voire pas du tout.

Les autres réponses ici donnent de bonnes raisons pour lesquelles. J'ai juste pensé qu'il serait utile d'avoir un compte rendu personnel.