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