Les tests unitaires sont-ils viables dans la programmation de jeux ?

Question

J'aime beaucoup l'idée des tests unitaires, mais j'ai du mal à l'appliquer à la programmation de jeux. Les jeux sont très évolutifs et souvent le code ne se décompose pas en unités distinctes. D'après mon expérience, la plupart des fonctions modifient l'état plutôt que de renvoyer des valeurs.

Prenons l'exemple d'une action simple comme playerJump(height) . J'aimerais avoir une suite de tests qui vérifie une grande variété de cas pour s'assurer que le saut fonctionne toujours comme prévu. Cependant, cette fonction ne renverra probablement aucune valeur et aura l'effet secondaire de , player.velocity.y = -height y checkCollisions(player) . Je n'arrive pas à trouver un test unitaire clair à construire autour de cela.

Les tests unitaires ne sont-ils tout simplement pas viables dans les applications à état élevé comme les jeux ? Les avantages des tests unitaires sont-ils si importants qu'il vaille la peine de programmer les jeux de manière fonctionnelle ?

---

Mise à jour :

Games from Within propose une série d'articles détaillés sur l'utilisation du développement piloté par les tests dans les jeux. Je les recommande vivement à toute personne intéressée par ce sujet. Voici le premier article :

http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Answer 1

Souvent, le code ne se décompose pas en unités distinctes.

C'est tout simplement une mauvaise conception. Le code ne se décompose pas en quoi que ce soit. En tant que concepteur, vous devez imposer une structure au code afin de pouvoir démontrer qu'il fonctionne réellement.

Cependant, cette fonction ne renverra probablement aucune valeur...

Et alors ?

...et ont pour effet secondaire de.., player.velocity.y = -height y checkCollisions(player) .

Il s'agit alors d'un test.

Je ne vois pas de test unitaire clair à construire autour de cela.

Pourquoi pas ? Vous venez de donner une excellente spécification pour les résultats de la fonction.

Vous pourriez avoir besoin de quelques objets fictifs pour remplacer le lecteur complet par un MockPlayer simplifié, plus facile à tester.

Mais votre spécification du comportement était parfaite. Il suffit de tester les choses que vous avez décrites.

Answer 2

Les tests unitaires peuvent être utiles pour un grand nombre de bibliothèques de bas niveau que vous pouvez utiliser avec le code du jeu, mais je doute sérieusement qu'ils soient d'une grande utilité pour les choses de plus haut niveau. Les jeux sont généralement des simulations et s'appuient sur des quantités massives d'états partagés qui ne peuvent pas être modélisés et testés de manière significative de manière isolée. Souvent, les fonctions des jeux ne renvoient pas de valeur que l'on puisse vérifier instantanément, mais déclenchent un processus qui doit s'achever à un moment donné dans le futur. Tester un tel comportement est intéressant, mais nécessite une approche très différente de l'idée du test unitaire, qui consiste à tester des morceaux de code de manière isolée.

Answer 3

La programmation, c'est la programmation. Les tests unitaires sont utiles pour tout type d'application car ils vous aident à détecter et à corriger les erreurs (et souvent, plus important encore, les régressions introduites par inadvertance lors de la refonte du code) immédiatement et efficacement.

Il y a bien sûr des domaines de comportement de haut niveau qui sont difficiles à tester de manière unitaire, mais ce n'est pas vraiment à cela que servent les tests unitaires - ils servent avant tout à vérifier que des méthodes individuelles ou de petites parties de la base de code font ce qu'elles sont censées faire.

Pour les comportements de plus haut niveau, vous devez appliquer d'autres approches de test (tests de régression, par exemple : introduire une séquence fixe d'entrées dans le jeu et vérifier que vous obtenez les mêmes résultats à chaque fois, ou générer des vues de caméra à des endroits fixes dans un niveau et vérifier qu'elles génèrent toujours la même image (ou au moins une image raisonnablement similaire)).

Votre exemple de PlayerJump en est un. Vous pouvez effectuer des tests unitaires ou de régression en l'isolant avec des entrées constantes (placez par programme le personnage du joueur à un endroit fixe dans une scène de test simple et déclenchez l'événement de saut, puis vérifiez que ses collisions ou son lieu de repos final sont cohérents). En créant une bibliothèque d'objets différents sur lesquels le joueur peut sauter, vous pouvez couvrir un grand nombre de cas de test (par exemple, que le saut réussisse sur un espace de la distance maximale de saut prescrite).

En outre, les jeux nécessitent de nombreux tests de jouabilité (où de vrais utilisateurs jouent simplement). Cela permettra de trouver des cas bizarres que vous n'avez pas couverts avec les tests automatisés, mais surtout de répondre à une question à laquelle les tests automatisés ne répondront jamais : Est-ce que le jeu est "agréable" ? Est-ce que c'est "amusant" ? Ce sont des tests que seul un être humain peut effectuer.

Answer 4

Mon expérience des tests unitaires et automatisés lors du développement de Crysis 2 est disponible ici : http://yetanothergameprogrammingblog.blogspot.com/2010/06/aaa-automated-testing.html J'espère que cela vous aidera.

Résumé :

L'automatisation des tests a permis d'améliorer la stabilité des produits livrés et d'accroître la productivité des créateurs de contenu et des ingénieurs. Les tests automatisés sont un outil efficace pour améliorer la qualité du code et réduire les risques de devoir faire des heures supplémentaires. L'industrie du jeu

Answer 5

Je recommande vivement la méthode TDD. C'est l'un des moyens les plus sûrs de s'assurer que votre développement de jeux Le processus ne prend pas une tournure négative et ne s'engage pas dans une mauvaise voie sans s'en rendre compte.