Unidade testando um projeto de jogo em C # / XNA

Eu tenho me envolvido no desenvolvimento de jogos desde que comecei a programar, mas nunca muito a sério. Trabalho como desenvolvedor de aplicativos de negócios, mas estou trabalhando em alguns jogos no meu tempo livre.

No mundo dos negócios (na pilha de desenvolvimento da Web da Microsft), o ASP.NET MVC está se tornando realmente popular, devido à sua facilidade de teste de unidade da maneira como a interface funciona.

Eu estou querendo saber quais padrões de design (MVC, MVP, MVVM, etc) se poderia usar para escrever um jogo no qual toda a lógica do jogo é facilmente testável por unidade. Isso é possível ou viável? Estou perdendo meu tempo, é melhor fazer compilações completas e executar testes do tipo "integração" em vez de testes de unidade?

O código de exemplo seria ótimo, mas uma redação também é útil.

(Tentei adicionar uma tag de teste de unidade, mas não tenho o representante necessário ...)

— Nate
fonte

Aqui está um bom artigo que eu descobri que descreve uma arquitetura para separar a funcionalidade para torná-la não apenas facilmente reutilizável, mas também potencialmente muito mais fácil para testar a unidade:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Alguns jogos se beneficiarão de um padrão semelhante ao MVC. Jogos de tabuleiro como xadrez e jogos de cartas vêm à mente. Na maioria dos casos, porém, isso é um exagero enorme.

Pessoalmente, acho que é suficiente apenas testar coisas de natureza algorítmica. Coisas das quais você dependerá para "simplesmente funcionar" quando estiver escrevendo código de jogo e podem ser insidiosamente difíceis de localizar problemas, se não o fizerem. Coisas como testes de interseção ou código de rede.

(Coisas que idealmente serão incorporadas a uma estrutura de terceiros para que você não precise escrevê - las ou testá-las!)

Uma técnica que eu gosto de usar para testar coisas relacionadas a jogos é o que eu chamo de "teste visual de unidade". O conceito básico é uma renderização de linha simples do bit de código em questão (por exemplo, uma função de interseção) e algumas atribuições básicas de teclas ou mouse para manipular as entradas. Ninguém disse que os testes de unidade precisam ser automatizados - eles apenas precisam dividir as coisas em unidades individuais e testá-las.

— Andrew Russell
fonte

Boa resposta. Eu também queria postar exatamente esse artigo. Os sistemas de componentes do Game Object são uma ótima maneira de separar a lógica e poder testá-los individualmente. O que nenhum teste de unidade pode fazer, no entanto, são as interações complexas de vários caminhos da lógica do jogo, interagindo em tempo real em sequência aleatória. Seria como tentar testar a previsão do tempo. :)

— LearnCocos2D

Sim, eu também faço pequenos testadores que isolam bits específicos de funcionalidade. Certifico-me de todas as alterações que faço nas APIs etc. Sempre certifico-me de que ainda funcionem. Muito mais fácil reutilizar a funcionalidade em seu próximo projeto.

— Iain

Sim, boa resposta, e eu gosto do link. E eu concordei com tudo, até a última linha: "Ninguém disse que os testes de unidade precisam ser automatizados". :) É preciso, talvez não - mas tudo o que li implica (ou diz diretamente) que os testes de unidade devem ser automatizados , a ponto de você pressionar apenas um botão para executar todos os seus testes. Caso contrário, quanto mais trabalho envolvido na execução dos testes, menor a probabilidade de você executá-los com bastante frequência. É verdade que, se você está falando sobre código de exibição , pode ser muito mais difícil fazer o teste de unidade, se possível.

— Ciclope

Quase quatro anos depois, sinto que desenvolvi uma melhor compreensão do porquê o "teste de unidade visual" funciona tão bem: Os testes de unidade são uma ferramenta de desenvolvimento. Um teste de unidade automatizado típico pode dizer que algo está quebrado. Mas um teste de unidade visual pode permitir que você explore algoritmos muito complicados e ajude a identificar rapidamente por que algo está quebrado (principalmente quando combinado com a edição de código ao vivo). Muitas vezes, um teste visual pode identificar problemas que, de outra forma, você teria que esperar para testar com código, ou problemas em que não há resposta "certa" (por exemplo: ajuste).

— Andrew Russell

E a idéia de que os testes de unidade precisam ser executados "com bastante frequência" (como em: sempre, de maneira automatizada) é falsa. Código que não muda obviamente não precisa ser re-testado. E quando o código está sendo modificado, o desenvolvedor que faz as modificações deve fazê-lo enquanto utiliza os testes disponíveis apropriados (visual, baseado em código ou outro). Obviamente, existe um código com um certo perfil de risco em que um teste automatizado é um investimento que vale a pena. Mas esses cenários são especialmente raros no desenvolvimento de jogos.

— Andrew Russell