Je suis juste curieux car tous les exemples de TDD que j'ai vus sont liés à la programmation web. Et si ce n'est pas une approche normale, pourquoi ne l'est-elle pas ?
Réponses
Trop de publicités?
Le TDD est devenu une approche privilégiée par les développeurs de logiciels qui prennent leur métier au sérieux. [ IEEE:TDD ] Les avantages de l'approche sont importants, et les coûts sont faibles en comparaison. [ Les trois lois du TDD ]
Il n'existe aucun domaine logiciel pour lequel la TDD est inappropriée ou inefficace. Cependant, il y a des domaines dans lesquels elle est difficile. Les jeux vidéo en font partie.
En fait, le défi n'est pas tant le jeu que l'interface utilisateur. La raison pour laquelle l'interface utilisateur est un défi est que vous ne savez souvent pas à quoi vous voulez que l'interface utilisateur ressemble avant de l'avoir vue. L'interface utilisateur est l'une de ces choses que l'on doit manipuler. La mettre au point est un processus profondément itératif, plein de rebondissements, d'impasses et de chemins de traverse. Écrire des tests premièrement pour l'assurance-chômage risque d'être à la fois difficile et source de gaspillage.
Avant que tout le monde ne s'exclame : "Oncle Bob dit : 'Ne faites pas de TDD pour l'interface utilisateur'", laissez-moi vous dire ceci. Le fait qu'il soit difficile de faire du TDD pur pour l'interface utilisateur ne signifie pas que vous ne pouvez pas faire du TDD pur pour presque tout le reste. La plupart des jeux sont basés sur des algorithmes, et vous pouvez utiliser TDD avec ces algorithmes pour votre plus grand plaisir. Il est vrai, surtout dans le domaine des jeux, que certains de ces algorithmes sont le genre de code que vous devez manipuler, tout comme l'interface utilisateur, et qu'il n'est donc probablement pas possible de les tester. premièrement . Mais il y a beaucoup d'autres codes algorithmiques qui peuvent et doivent être écrits en test d'abord.
L'astuce ici est de suivre le Principe de responsabilité unique (PRU) et séparer les types de code que vous devez manipuler, de ceux qui sont déterministes. Ne mettez pas d'algorithmes faciles à tester avec votre interface utilisateur. Ne mélangez pas votre code spéculatif avec votre code non spéculatif. Gardez les éléments qui changent pour la raison A séparés des éléments qui changent pour la raison B. .
Gardez également ceci à l'esprit : Le fait que certains codes sont difficiles à tester premièrement ne signifie pas que ce code est difficile à tester. deuxième . Une fois que vous avez manipulé et modifié le code pour qu'il fonctionne comme vous le souhaitez, puis vous pouvez écrire les tests pour démontrer que le code fonctionne comme vous le pensez. (Vous serez surpris du nombre de fois où vous trouverez des bogues en faisant cela).
Le problème de l'écriture de tests "après coup" est que, souvent, le code est tellement couplé qu'il est difficile d'écrire les types de tests chirurgicaux qui sont les plus utiles. Donc si vous écrivez le genre de code qu'il est difficile de tester premièrement vous devez prendre soin de suivre Le principe d'inversion des dépendances (DIP) et Le principe d'ouverture et de fermeture (OCP) afin de garder le code suffisamment découplé pour le tester après coup.
Chris Howe
Points
181
La réponse simple est "non", TDD n'est pas une approche normale dans le développement de jeux. Certaines personnes citeront Highmoon et Neil Llopis comme contre-exemples, mais il s'agit d'une grande industrie et ce sont les seules personnes que je connaisse qui ont pleinement adopté la TDD. Je suis sûr qu'il y en a d'autres, mais ce sont les seuls que je connaisse (et je travaille dans ce secteur depuis 5 ans).
Je pense que beaucoup d'entre nous se sont essayés aux tests unitaires à un moment ou à un autre, mais pour une raison ou une autre, ils n'ont pas pris le dessus. D'après mon expérience personnelle, il est difficile pour un studio de jeux de passer au TDD. Habituellement, une base de code est conservée d'un projet à l'autre, et appliquer la TDD à une large base de code existante est à la fois fastidieux et largement ingrat. Je suis sûr que cela peut s'avérer fructueux à terme, mais il est difficile de faire adhérer les codeurs de jeux à cette méthode.
J'ai eu un certain succès dans l'écriture de tests unitaires pour le code de bas niveau du moteur de jeu, car ce code a tendance à avoir très peu de dépendances et est facilement encapsulé. Mais il s'agissait toujours de tests après coup et non de TDD. Le code de jeu de plus haut niveau est généralement plus difficile à écrire des tests car il a beaucoup plus de dépendances et est souvent associé à des données et des états complexes. Prenons l'exemple de l'IA. Pour tester l'IA, il faut une sorte de contexte, c'est-à-dire un maillage de navigation et d'autres objets dans le monde. Mettre en place ce type de test de manière isolée peut s'avérer non trivial, surtout si les systèmes concernés n'ont pas été conçus pour cela.
Ce qui est plus commun dans le développement de jeux, et avec lequel j'ai eu plus de succès personnel, est le test de fumée. Vous verrez souvent des tests de fumée utilisés en conjonction avec l'intégration continue pour fournir divers types de retours sur le comportement du code. Les tests fumigènes sont plus faciles parce qu'ils peuvent être effectués en introduisant simplement des données dans le jeu et en lisant les informations en retour, sans avoir à compartimenter votre code en petits morceaux testables. En reprenant l'exemple de l'IA, vous pouvez demander au jeu de charger un niveau et fournir un script qui charge un agent d'IA et lui donne des ordres. Ensuite, vous déterminez simplement si l'agent exécute ces commandes. Il s'agit d'un test de fumée plutôt que d'un test unitaire car vous exécutez le jeu dans son ensemble et ne testez pas le système d'IA de manière isolée.
À mon avis, il est possible d'obtenir une couverture de test décente en testant à l'unité le code de bas niveau tout en testant en fumée les comportements de haut niveau. Je pense (j'espère) que d'autres studios adoptent également une approche similaire.
Si mon opinion sur le TDD semble quelque peu ambiguë, c'est parce qu'elle l'est. Je suis encore un peu hésitant à ce sujet. Si j'en vois certains avantages (tests de régression, accent mis sur la conception avant le code), l'appliquer et le faire respecter tout en travaillant avec une base de code préexistante semble être une recette pour des maux de tête.
Josh Kelley
Points
24438
Games from Within a un article discuter de leur utilisation des tests unitaires, des limites de ces tests en ce qui concerne les jeux en particulier, et d'un serveur de tests fonctionnels automatisés qu'ils ont mis en place pour les aider.
Rune Braathen
Points
136
Si vous faites référence à la pratique consistant à écrire et à maintenir des tests unitaires pour chaque partie du code, je me risquerais à dire que cette pratique n'est pas très répandue dans l'industrie du jeu. Il y a de nombreuses raisons à cela, mais je peux penser à trois raisons évidentes :
- Culturel. Les programmeurs sont conservateurs, les programmeurs de jeux le sont doublement.
- Pratique. La TDD ne s'adapte pas très bien au domaine du problème (trop de pièces mobiles).
- Crunchologique. On n'a jamais assez de temps.
Le paradigme TDD fonctionne mieux dans les domaines d'application qui n'ont pas beaucoup d'état, ou du moins où les pièces mobiles ne bougent pas toutes en même temps, pour le dire familièrement.
La méthodologie TDD est applicable à certaines parties du processus de développement des jeux (bibliothèques de base et autres), mais les "tests" dans ce domaine signifient généralement l'exécution de tests automatisés, de tests de touches aléatoires, le chronométrage des chargements d'instructions, le suivi des pics d'images par seconde, la vérification que le joueur ne peut pas se faufiler et provoquer des instabilités visuelles, etc. L'automate est aussi très souvent un humanoïde.
Le TDD peut être un outil utile, mais son statut de solution miracle qui doit être omniprésente lors de la création d'un système est plutôt discutable. Le développement ne devrait pas être guidé par les tests, mais par la raison. RDD est un acronyme pourri - il ne sera pas adopté ;)
MSN
Points
30386
La plupart des développeurs de jeux ne sont pas vraiment au fait des pratiques de développement modernes. Heureusement.
Mais un modèle de développement piloté par les tests consiste à se concentrer d'abord sur la façon dont une chose sera utilisée, puis à étoffer ce qu'elle fait. En général, c'est une bonne chose, car cela vous oblige à vous concentrer sur la façon dont une fonctionnalité particulière s'intégrera réellement dans ce que vous faites (un jeu, par exemple).
Les bons développeurs de jeux le font donc naturellement. Mais pas de manière explicite.
