Le BDD (Behavior Driven Development) est-il utilisé dans les jeux?


9

Je lis sur BDD - Behaviour Driven Development depuis un certain temps, et je trouve très facile et utile de convertir des fonctionnalités en code. Les utilisateurs de BDD l'appellent souvent TDD bien fait.

BDD est un outil de conception de logiciels, de l'extérieur vers l'intérieur, de la valeur commerciale (ou valeur de gameplay) au code.

Dan North présente BDD

Connaissez-vous d'autres ressources sur le BDD et les jeux que celle-ci ?


Cela ressemble à une adaptation de TDD, et en tant que tel, ce lien est à peu près un doublon.
The Communist Duck

Comme le BDD est un processus bien organisé pour faire du TDD, j'aimerais savoir si quelqu'un l'utilise et quelle est l'expérience.
MarcoTmp

Cette question ne répond-elle pas à vos questions?
The Communist Duck

Pas vraiment, car je ne sais toujours pas comment les autres utilisent le BDD dans les jeux.
MarcoTmp

J'ai toujours l'impression qu'il s'agit essentiellement de TDD exécuté dans un style différent.
The Communist Duck

Réponses:


14

Il est probablement sûr de dire que BDD, comme TDD, ou (insérer le mot-clé de développement à la mode ici) est utilisé par certains développeurs de jeux quelque part, mais ils ne savent probablement pas qu'ils le sont et ne seraient pas nécessairement en mesure d'identifier ce que signifie réellement BDD . La question est vraiment combien ils l'utilisent et combien doivent- ils l' utiliser pour que cela vous importe?

Par exemple, là où je travaille, tous nos noms de tests unitaires sont des "phrases" comme Dan North le suggère dans cet article que vous avez lié. Cela seul ne suffit pas pour dire que nous utilisons le BDD, bien sûr, mais c'est peut-être ce qui vous intéresse vraiment?

À mon avis, l'accent ne devrait pas être mis sur le mot à la mode que vous appliquez dans un studio, mais plutôt sur les techniques de productivité et de processus de développement que vous utilisez dans l'ensemble. Je trouve que les équipes les plus productives mélangent et associent les techniques d'une variété de «paradigmes de mots à la mode» plutôt que de s'engager, dogmatiquement, dans chaque partie de la doctrine rigide selon une étude Internet, comprend un paradigme de mots à la mode particulier.

Je le constate le plus souvent avec la tendance Agile: les équipes qui s'identifient comme "faisant de l'Agile" ont tendance à être plus inflexibles (ironiquement) au sujet du processus que les équipes qui incorporent organiquement les morceaux d'Agile qui ont du sens pour elles. D'après mon expérience, les anciennes équipes finissent presque toujours par être moins productives.

Une équipe de développement est composée d'humains, qui ne sont pas des rouages ​​interchangeables dans une machine. Ils opèrent uniquement en tant qu'individus et en tant que combinaison unique d'eux-mêmes. La voie vers un développement efficace n'est pas de plier vos humains dans le moule {BDD, Agile, WwhatIsNext} mais de réévaluer constamment la façon dont l'équipe progresse et de renforcer les lacunes dans le processus, de remplacer les technologies cassées et de renforcer les choses qui sont travail. En bref, se concentrer sur l'expédition d'un titre et non sur "être Agile (ou autre)".


Je dois bien sûr noter que je n'ai ici que des preuves anecdotiques par rapport à mes commentaires sur le lien entre l'adhésion catégorique au dogme du processus et la productivité. C'est juste mon expérience et non une étude scientifique.

1
-1. Merci pour votre avis. Voulez-vous répondre à la question?
Jess Telford

+1, belle réponse. @JoshPetrie Utilisez-vous au moins parfois TDD ou mesurez-vous la couverture des tests? Juste intéressant l'état des tests des développeurs dans le développement de jeux.
Ilya Ivanov le

1

C'est ça? Peut être. À mon avis, cela ferait un très mauvais ajustement pour les logiciels de divertissement en général, même si cela pourrait bien fonctionner pour les bibliothèques de bas niveau.

EDIT: Voici une justification de mon opinion.

Wikipédia définit le BDD comme une technique qui "encourage la collaboration entre les développeurs, le contrôle qualité et les participants non techniques ou commerciaux à un projet logiciel". Cela semble déjà être une mauvaise idée car les jeux diffèrent de la plupart des logiciels en ce qu'ils ne sont pas conçus comme des outils pour répondre à un besoin spécifique d'un `` participant non technique ou professionnel '', mais sont des œuvres cohérentes largement conçues pour divertir. L'accent est mis sur le «comportement logiciel souhaité», mais les jeux ont rarement le «comportement logiciel souhaité», sauf au niveau technique. Il est certainement intéressant de vérifier cette partie du code, mais pas avec l'utilisateur final, car ils ne le verront jamais.

Mais supposons que vous vouliez jeter ces trucs de parties prenantes humaines et utiliser simplement BDD pour appliquer des contrats entre différents modules de code, ce qui, à ma connaissance, ne diffère pas beaucoup du développement normal piloté par les tests, que je considère également mal- adapté aux jeux, pour la raison suivante.

Les tests sont utiles pour vérifier que des événements discrets se sont produits comme prévu. Cela fonctionne bien dans la programmation événementielle, c.-à-d. la plupart du monde du logiciel, où une action est effectuée, une sortie est générée, puis vous vérifiez simplement que l'action et le résultat correspondent. Cependant, le logiciel de jeu est généralement une simulation, où une action n'a pas un résultat discret mais un changement continu de l'état du monde. Si mon joueur caché fait du bruit, je pourrais vouloir vérifier que l'IA me traque. Donc, je peux créer un test pour m'assurer que l'IA est en état de «chasse» après la création d'un bruit, et c'est génial. Mais comment puis-je savoir que la chasse fonctionne même? Vous ne pouvez pas le vérifier instantanément - vous ne pouvez l'observer qu'au fil du temps.

De plus, une approche basée sur le test peut créer un faux sentiment de sécurité et amener les gens à croire que le code est meilleur qu'il ne l'est vraiment.

def check_dice_roll_in_range():
    d = new Dice()
    assert(d.roll() between 1 and 6)

class Dice:
    def roll():
        return 4

Puisqu'un résultat de test peut donner un faux positif, vous ne pouvez jamais échapper au besoin de base de vérifier le code lui-même. Mais si le code lui-même est vérifié correctement, le test prend une importance secondaire. C'est pourquoi, à mon avis, les tests sont mieux utilisés après l'événement, pour tester les corrections de bugs.

Je ne dirais pas qu'il n'y a jamais aucun avantage à tester que, lorsque les objets X et Y fonctionnent ensemble, le résultat que vous obtenez est comme prévu. La question est de savoir si vous utilisez le moyen le plus efficace de vérifier cela. Les méthodes peuvent inclure une vérification formelle, une révision du code, des méthodes de test en premier, des méthodes de test en dernier, des tests de boîte noire AQ traditionnels, ou simplement en utilisant le code comme prévu et en observant les résultats. Les deux dernières options sont étonnamment efficaces la plupart du temps, car malgré le fait qu'elles semblent manquer de rigueur, la plupart des bogues sont détectés au cours d'une utilisation typique, et comprendre un bogue dans son contexte naturel peut parfois être plus facile que de le comprendre dans un test artificiel. harnais. En plus de cela,

Donc, en résumé, je pense que le développement piloté par les tests n'est pas nécessairement un excellent choix pour les logiciels, que les tests seuls ne sont jamais suffisants pour garantir la qualité des logiciels (et donc le temps passé à les écrire doit être comparé aux utilisations alternatives de ce temps de développeur), que les jeux correspondent particulièrement mal aux scénarios de test automatisés, et que les jeux correspondent particulièrement aux méthodes de développement qui mettent l'accent sur la «valeur commerciale» et les «tests d'acceptation».

(J'espère que c'est une meilleure réponse, même si vous n'êtes pas d'accord avec mes points.)


-1 de moi aussi; au contraire, BDD est encore mieux adapté aux jeux qu'à d'autres choses. Il est encore plus naturel de spécifier le comportement d'un caractère en réponse à une entrée que de spécifier le comportement d'un service Web en réponse à un message XML donné.
BlueRaja - Danny Pflughoeft

1
Le logiciel de divertissement est toujours un logiciel, n'est-ce pas?
prusswan

Une bonne variété d'opinions d'experts est très précieuse, à mon humble avis. Chaque personne a un badge de représentant sur ses réponses, afin que les lecteurs puissent imaginer dans quelle mesure peser l'opinion lorsqu'elle est prise conjointement avec le reste affiché pour une question particulière.
Nate

1
Je maintiens mon -1, et je voudrais répondre à ce qui a été dit: collaboration between developers, QA and [users] [...] sounds like a bad idea - games rarely have 'desired software behaviour'- oui, ils le font: ils doivent être amusants. La meilleure façon de savoir si votre jeu est amusant est d'écouter les testeurs. Les développeurs sont souvent aveuglés par leur création (ou par des difficultés techniques) au fait que leur jeu n'est pas amusant. Les testeurs non développeurs n'ont pas ces problèmes.
BlueRaja - Danny Pflughoeft

2
Quant aux tests: si c'est comme ça que vous écrivez des tests, alors vous le faites complètement mal. Ex. pour tester Dice, vous devez passer un objet aléatoire simulé et vous assurer de Roll()renvoyer les valeurs correctes. Vous utilisez exactement les mêmes techniques pour tester des simulations (jeux vidéo) que vous faites pour tester des applications normales. Les tests unitaires ne peuvent que tester des unités - vous avez donc raison de dire que «les tests seuls ne sont jamais suffisants pour garantir la qualité du logiciel» (c'est pourquoi l'AQ existe toujours). Mais cela ne signifie pas qu'ils sont moins utiles pour les jeux vidéo.
BlueRaja - Danny Pflughoeft

1

Je pense que BDD est approprié dans chaque environnement. Comme d'autres l'ont mentionné, vous développez un logiciel et, par conséquent, vous devriez le tester. J'aime bdd pour certaines des sémantiques aléatoires mentionnées comme les noms de test comme phrases. J'aime aussi regrouper certains tests tout en étant capable de tester 1 classe.

Pour combattre d'autres messages ici, je voudrais souligner que sur un projet plus vaste, il est BEAUCOUP plus difficile de refactoriser le code sans tests. Si vous refactorisez un code, vous volez aveuglément pour savoir si tout va exploser dans une lueur de gloire ou non. Les tests vous aident à attraper les choses tôt. Donc, vous écrivez votre test, échouez, codez juste assez pour réussir et continuer. Lorsque vous refactorisez, vous devez faire la même chose, mais plutôt que d'écrire, vous révisez le test. Dans la plupart des cas, vous exécutez le test, il échouera, vous changerez ce que vous pensez qu'il devrait changer et il échouera ENCORE. À ce stade, vous vous rendez compte qu'un autre morceau de code repose sur cette fonction / méthode d'une manière complètement différente. Vous pouvez ensuite corriger votre test et le code résultant. Sans ce type de couverture de code, vous trébucheriez pendant des jours à essayer de trouver où les choses sont cassées,

Allez lire sur "Contrats" dans le livre du Pragmatic Progammer. Les tests vous aident à conclure des contrats de code. Ce code fait X et rien de plus que X et ne s'attend pas à ce qu'il fasse quoi que ce soit à propos de Y ou n'essaye pas de l'adapter pour faire Z. Il assure la propreté du code et s'attend à ce que tout le monde ne soit pas une bite et boue dans la base de code.

Le BDD a plus de raisons. Le principal pour moi est que je ferais le même nombre de tests pour valider mes hypothèses de toute façon, donc je pourrais aussi bien le formaliser.

Au point de "comment" cela dépend vraiment de votre environnement. J'écris un jeu java maintenant et j'utilise robolectric. Vous devriez toujours essayer de «vous attendre» à quelque chose. J'ai entendu dire que les espions / maquettes / talons ne sont pas aussi utiles car vous devez avoir l'équivalent de l'autre côté, mais parfois vous n'avez pas le choix, en particulier avec les API. Vous pouvez supposer que l'autre côté de l'API n'est pas terrible et c'est généralement votre code qui est nul.

Si par exemple vous testez le mouvement. Eh bien, vous vous attendez lorsque vous appuyez sur "Haut" que l'utilisateur avance d'une certaine mesure.

Si, par exemple, vous testez le rendu graphique ... eh bien, ne testez pas trop parce que vous faites vraiment ça? Un bon cadre de test pourrait gérer cette partie pour vous. La réflexion n'est pas super triviale, je dirais pour ce genre de choses. Vous devrez peut-être vérifier les tampons, etc., etc. Je vérifierais simplement ce que vous faites réellement. Le personnage est là, maintenant il est là après une action.

Vous devriez avoir plein de minuscules petites fonctions / tests et ensemble ils résumeront en quelque chose d'utile.


Oh, enfin, j'ai remarqué que beaucoup de gens arrivaient à avoir le bon comportement lors du codage des jeux / graphiques. Tester un peu empêche cet effet "ça marche un peu". Il est beaucoup plus difficile de SAVOIR comment vos équations affecteront les choses que de simplement copier du code et de faire des hypothèses.
Parris

BDD ne concerne pas seulement les tests, mais cela va bien au-delà.
Daniel

0

Je pense qu'il y a une idée fausse sur ce qu'est le BDD. Le BDD n'est pas une technique ou un processus de TEST. BDD est un modèle et un processus de développement. Cela va bien au-delà des tests et va bien au-delà de la programmation.

En tant que tel, je ne connais aucun studio AAA majeur travaillant avec ce modèle (j'ai des amis travaillant pour certains d'entre eux dans le monde en tant que programmeurs). Comme quelqu'un l'a souligné, il se peut qu'un gestionnaire de projet ou une équipe intègre quelque part certaines des pratiques que BDD englobe, mais je ne connais aucun studio appliquant le BDD pur (de la définition de la valeur commerciale, de la spécification par exemple, à l'écriture). fichiers de fonctionnalités, pour les valider auprès des actionnaires, pour automatiser les fichiers de fonctionnalités en tant que tests).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.