Test unitaire d'un projet de jeu C # / XNA

Je me connecte au développement de jeux depuis que j'ai commencé la programmation, mais jamais très sérieusement. Je travaille en tant que développeur d'applications professionnelles, mais je travaille sur certains jeux pendant mon temps libre.

Dans le monde des affaires (sur la pile de développement Web de Microsft), ASP.NET MVC est en train de devenir très populaire, en raison de sa facilité à tester de manière unitaire le fonctionnement de l'interface.

Je me demande quels modèles de conception (MVC, MVP, MVVM, etc.) on pourrait utiliser pour écrire un jeu dans lequel toute la logique du jeu est facilement testable par unité. Est-ce possible ou faisable? Suis-je en train de perdre mon temps, est-il préférable de faire des builds complets puis d'exécuter des tests de type «intégration» au lieu de tests unitaires?

Un exemple de code serait bien, mais une écriture est également utile.

(J'ai essayé d'ajouter une balise de test unitaire, mais je n'ai pas le représentant requis ...)

— Nate
source

Voici un bon article que j'ai trouvé qui décrit une architecture pour séparer les fonctionnalités afin de les rendre non seulement facilement réutilisables, mais aussi potentiellement beaucoup plus faciles à tester unitaire:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Certains jeux bénéficieront d'un modèle de type MVC. Les jeux de société comme les échecs et les jeux de cartes me viennent à l'esprit. Dans la plupart des cas, cependant, c'est une surpuissance massive.

Personnellement, je trouve qu'il suffit de tester uniquement des éléments de nature algorithmique. Les choses sur lesquelles vous dépendrez pour «fonctionner tout simplement» lorsque vous écrivez du code de jeu, et peuvent être insidieusement difficiles à détecter les problèmes, si elles ne le font pas. Des choses comme les tests d'intersection ou le code de mise en réseau.

(Les choses qui, idéalement, seront intégrées dans un cadre tiers afin que vous n'ayez pas à les écrire ou les tester!)

Une technique que j'aime utiliser pour tester les éléments liés au jeu est ce que j'appelle le "test unitaire visuel". Le concept de base étant un simple rendu de ligne du bit de code en question (par exemple une fonction d'intersection), et quelques affectations de base de touches ou de souris pour manipuler les entrées. Personne n'a dit que les tests unitaires devaient être automatisés - ils devaient simplement décomposer les éléments en unités individuelles et les tester.

— Andrew Russell
source

Bonne réponse. Je voulais également publier exactement cet article. Les systèmes de composants Game Object sont un excellent moyen de séparer la logique et de pouvoir les tester individuellement. Cependant, ce qu'un test unitaire ne peut pas faire, ce sont les interactions complexes de plusieurs chemins de logique de jeu interagissant en temps réel dans une séquence aléatoire. Ce serait comme essayer de tester les prévisions météorologiques. :)

— LearnCocos2D

Oui, je fais aussi des petits testeurs qui isolent des bits de fonctionnalité particuliers. Je m'assure que toutes les modifications que j'apporte aux API, etc. Je m'assure toujours que celles-ci fonctionnent toujours. Il est beaucoup plus facile de réutiliser la fonctionnalité dans votre prochain projet.

— Iain

Oui, bonne réponse, et j'aime le lien. Et je suis d'accord avec tout jusqu'à la dernière ligne, "Personne n'a dit que les tests unitaires devaient être automatisés". :) Je le dois , peut-être pas - mais tout ce que j'ai lu implique (ou dit clairement) que les tests unitaires doivent être automatisés , au point que vous n'appuyez sur un seul bouton pour exécuter tous vos tests. Sinon, plus les tests impliquent de travail, moins vous avez de chances de les exécuter assez souvent. Certes, si vous parlez de code d' affichage , il peut être beaucoup plus difficile de faire des tests unitaires, si possible.

— Cyclops

Près de quatre ans plus tard, j'ai l'impression d'avoir mieux compris pourquoi le "test unitaire visuel" fonctionne si bien: les tests unitaires sont un outil de développement. Un test unitaire automatisé typique peut vous dire que quelque chose est cassé. Mais un test unitaire visuel peut vous permettre d'explorer des algorithmes très compliqués et vous aider à identifier rapidement pourquoi quelque chose est cassé (en particulier lorsqu'il est combiné avec l'édition de code en direct). Souvent, un test visuel peut identifier des problèmes que vous auriez autrement dû anticiper pour tester avec du code, ou des problèmes où il n'y a pas de «bonne» réponse (par exemple: réglage).

— Andrew Russell

Et l'idée que les tests unitaires doivent être exécutés "assez souvent" (comme dans: toujours, de manière automatisée) est fausse. Le code qui ne change pas n'a évidemment pas besoin d'être re-testé. Et lorsque le code est en cours de modification, le développeur qui effectue les modifications doit le faire tout en utilisant les tests disponibles appropriés (visuels, basés sur le code ou autre). Évidemment, il existe un code avec un certain profil de risque où un test automatisé est un investissement de temps intéressant. Mais de tels scénarios sont particulièrement rares dans le développement de jeux.

— Andrew Russell