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

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 ?

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)".

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.)

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.

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).