O BDD (Behavior Driven Development) é usado em jogos?

Eu tenho lido sobre o BDD - Behavior Driven Development há algum tempo e acho realmente fácil e útil converter recursos em código. Os usuários do BDD costumam chamá-lo de TDD corretamente.

O BDD é uma ferramenta para design de software, de fora para dentro, do valor do negócio (ou do jogo) ao código.

Dan North apresenta o BDD

Você conhece algum recurso sobre o BDD e jogos além deste ?

Provavelmente, é seguro dizer que o BDD, como o TDD, ou (insira o paradigma da palavra-chave do desenvolvimento da moda aqui) é usado por alguns desenvolvedores de jogos em algum lugar, mas provavelmente eles não sabem o que são e nem seriam capazes de identificar o que o BDD realmente significa . A questão é realmente quanto eles usam e quanto eles têm que usá-lo para que isso seja importante para você?

Por exemplo, onde trabalho, todos os nossos nomes de teste de unidade são "sentenças", como sugere Dan North no artigo que você vinculou. Isso por si só não é suficiente para dizer que usamos o BDD, é claro, mas talvez seja com isso que você realmente se preocupa?

O foco, na minha opinião, não deve ser qual palavra da moda você aplica em um estúdio, mas quais técnicas de processo de produtividade e desenvolvimento são empregadas em geral. Acho que as equipes mais produtivas estão misturando e combinando técnicas de uma variedade de "paradigmas de palavras-chave" em vez de se comprometer, dogmaticamente, com toda a doutrina rígida que um estudo na Internet diz que compreende um paradigma-chave específico.

Vejo isso com mais frequência com a tendência do Agile: equipes que se identificam como "fazendo Agile" tendem a ser mais inflexíveis (ironicamente) sobre o processo do que equipes que incorporam organicamente os bits do Agile que fazem sentido para eles. As antigas equipes quase sempre acabam sendo menos produtivas, na minha experiência.

Uma equipe de desenvolvimento é composta por seres humanos, que não são engrenagens intercambiáveis ​​em uma máquina. Eles operam exclusivamente como indivíduos e como a combinação única de si mesmos. O caminho para o desenvolvimento eficaz não é inclinar seus humanos para o molde {BDD, Agile, WhateverIsNext}, mas estar constantemente reavaliando como a equipe está progredindo e sustentando deficiências no processo, substituindo as técnicas quebradas e reforçando as coisas que estão trabalhando. Em resumo, focar no envio de um título e não em "ser ágil (ou o que seja)".

É isso? Talvez. Minha opinião seria que isso resultaria em um ajuste muito ruim para o software de entretenimento em geral, embora possa funcionar bem para as bibliotecas de baixo nível.

EDIT: Aqui está uma justificativa para a minha opinião.

A Wikipedia define o BDD como uma técnica que "incentiva a colaboração entre desenvolvedores, controle de qualidade e participantes não técnicos ou de negócios em um projeto de software". Isso já parece uma péssima idéia, porque os jogos diferem da maioria dos softwares, pois não são projetados como ferramentas para atender a uma necessidade específica de um 'participante não técnico ou de negócios', mas são trabalhos coesos amplamente projetados para entreter. Há uma ênfase no "comportamento desejado do software", mas os jogos raramente têm 'comportamento desejado do software', exceto no nível técnico. Definitivamente, há mérito em verificar essa parte do código, mas não com o usuário final, porque eles nunca o verão.

Mas vamos supor que você queira descartar essas coisas das partes interessadas humanas e apenas usar o BDD para fazer cumprir contratos entre diferentes módulos de código, o que, até onde posso ver, não difere muito do desenvolvimento normal orientado a testes, que também considero pouco. adequado para jogos, pelo seguinte motivo.

Os testes são úteis para verificar se eventos discretos ocorreram quando esperado. Isso funciona bem na programação orientada a eventos, ou seja. na maior parte do mundo do software, em que uma ação é executada, é gerada alguma saída e você apenas verifica se a ação e o resultado são correspondentes. No entanto, o software do jogo é tipicamente uma simulação, onde uma ação não tem um resultado discreto, mas uma mudança contínua no estado mundial. Se meu player oculto fizer barulho, talvez eu queira verificar se a IA me persegue. Então, eu posso criar um teste para garantir que a IA esteja no estado 'caça' após a criação de um ruído, e isso é ótimo. Mas como sei que a caça funciona? Você não pode verificar isso instantaneamente - você só pode observá-lo ao longo do tempo.

Além disso, uma abordagem de teste primeiro pode criar uma falsa sensação de segurança e levar as pessoas a acreditar que o código é melhor do que realmente é.

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

class Dice:
    def roll():
        return 4

Como um resultado de teste pode dar um falso positivo, você nunca pode escapar da necessidade básica de verificar o próprio código. Mas se o próprio código for verificado adequadamente, o teste assume importância secundária. É por isso que, na minha opinião, os testes são melhor utilizados após o evento, para testar correções de bugs.

Eu não argumentaria que nunca há nenhum benefício em testar que, quando os objetos X e Y trabalham juntos, o resultado obtido é o esperado. O problema é se você está usando a maneira mais eficaz de verificar isso. Os métodos podem incluir verificação formal, uma revisão de código, métodos de primeiro teste, métodos de último teste, teste tradicional de caixa preta de controle de qualidade ou simplesmente usar o código conforme o esperado e observar os resultados. As duas últimas opções são surpreendentemente eficazes na maioria das vezes, porque, apesar de parecerem pouco rigorosas, a maioria dos erros é encontrada durante o uso típico, e entender um bug em seu contexto natural às vezes pode ser mais fácil do que entendê-lo em um teste artificial. arnês. Além do mais,

Portanto, em resumo, acho que o desenvolvimento orientado a testes não é necessariamente uma ótima opção para software, que os testes por si só nunca são suficientes para garantir a qualidade do software (e, portanto, o tempo gasto para escrevê-los deve ser comparado aos usos alternativos do tempo do desenvolvedor), que jogos são uma combinação especialmente ruim para casos de teste automatizados e que jogos são uma combinação especialmente ruim para métodos de desenvolvimento que buscam enfatizar o 'valor comercial' e o 'teste de aceitação'.

(Espero que seja uma resposta melhor, mesmo que você não concorde com os meus argumentos.)

Eu acho que o BDD é apropriado em todos os ambientes. Como outros mencionaram, você está desenvolvendo software e, como resultado, deve testá-lo. Eu gosto de BDD para algumas das semânticas aleatórias mencionadas como nomes de teste como sentenças. Também gosto de agrupar certos testes e ainda poder testar uma classe.

Para combater outras mensagens aqui, eu gostaria de salientar que em um projeto maior é MUITO mais difícil refatorar o código sem testes. Se você refatorar algum código, estará voando às cegas para saber se tudo vai explodir em um incêndio de glória ou não. Os testes ajudam você a entender as coisas cedo. Então você escreve seu teste, falha, codifica apenas o suficiente para passar e continuar. Ao refatorar, você deve fazer a mesma coisa, mas, em vez de escrever, você revisa o teste. Na maioria dos casos, você executa o teste, ele falha, você muda o que acha que deve mudar e AINDA falha. Nesse ponto, você percebe que algum outro pedaço de código depende dessa função / método de uma maneira completamente diferente. Você pode corrigir seu teste e o código resultante. Sem esse tipo de cobertura de código, você ficaria tropeçando por dias tentando descobrir onde as coisas estão quebradas,

Leia sobre "Contratos" no livro do Pragmatic Progammer. O teste ajuda a obter contratos de código. Esse código faz X e nada mais que X e não espera que faça nada sobre Y ou tente adaptá-lo ao Z. Ele garante a limpeza do código e espera que todos não sejam um idiota e confundam a base de código.

Há mais razões para o BDD. O principal para mim é que eu faria a mesma quantidade de testes para validar minhas suposições de qualquer maneira, para que eu possa formalizá-las.

No ponto de "como" isso realmente depende do seu ambiente. Estou escrevendo um jogo java agora e usando robolectric. Você deve sempre tentar "esperar" algo. Ouvi dizer que espiões / zombarias / stubs não são tão úteis, pois você precisa ter equivalente do outro lado, mas às vezes você não tem escolha, especialmente com APIs. Você pode supor que o outro lado da API não seja terrível e geralmente é o seu código que é péssimo.

Se, por exemplo, você estiver testando movimento. Bem, quando você pressiona "Para cima", o usuário avança por alguma medida.

Se, por exemplo, você está testando a renderização gráfica ... bem, não teste muito, porque realmente está fazendo isso? Uma boa estrutura de teste pode lidar com essa parte para você. Reflexão não é super trivial, eu diria para esse tipo de coisa. Você pode precisar verificar buffers, etc, etc. Basta verificar o que você está realmente fazendo. O personagem está aqui, agora ele está lá depois de alguma ação.

Você deve ter várias pequenas funções / testes e, juntos, eles resumirão algo útil.

Eu sinto que há um equívoco sobre o que é BDD. O BDD não é uma técnica ou processo de TESTE. O BDD é um modelo e processo de desenvolvimento. Vai MUITO além do teste e vai muito além da programação.

Como tal, não conheço nenhum grande estúdio AAA trabalhando com esse modelo (tenho amigos trabalhando para alguns deles em todo o mundo como programadores). Como alguém apontou, pode ser que algum gerente ou equipe de projeto, em algum lugar, incorpore algumas das práticas que o BDD abrange, mas eu não conheço nenhum estúdio que aplique BDD puro (da definição de valor de negócios, à especificação por exemplo, à escrita) validar com os acionistas, automatizar os arquivos como testes).