Quão comum é o teste automatizado no desenvolvimento de jogos? [fechadas]

Os desenvolvedores de gamers usam para escrever testes de unidade e integração? Quão comum é isso entre os desenvolvedores de quebra-cabeças? E entre os desenvolvedores de MMORPGs e FPSes?

(Não tenho experiência em desenvolvimento de jogos nem estou cogitando em trabalhar com ele - é apenas uma dúvida que me ocorreu. Portanto, não há necessidade de tentar me convencer a escrevê-los, mesmo porque já gosto de escrever testes automatizados. )

Em geral, o teste de unidade e integração de jogos não é tão comum. Isso ocorre principalmente porque o aspecto de renderização dos jogos geralmente está intimamente ligado ao restante da mecânica do jogo e pode ser muito difícil escrever testes de unidade que funcionem.

Dito isto, o teste de unidade pode acontecer no desenvolvimento de jogos e, se o código estiver configurado para ele, pode ser de grande benefício. No entanto, pode ser muito mais comum escrever testes automatizados para jogos, geralmente na forma de um programa de IA que pode efetivamente jogar o jogo em uma velocidade mais alta do que um jogador normal. Há algumas histórias excelentes de desenvolvedores fazendo exatamente isso nesta pergunta sobre testes automatizados . Esse tipo de teste automatizado é potencialmente melhor, pois o teste de unidade pode não detectar um erro no mecanismo de renderização, mas é mais provável que um teste automatizado exponha esse problema.

No final, porém, tudo isso depende do estúdio. Alguns estúdios farão algum tipo de teste automatizado, enquanto outros podem contratar 20 alunos do ensino médio durante o verão para jogar por horas a fio.

Na minha experiência, não é muito comum.

Principalmente o teste de unidade não ocorre porque a maioria dos desenvolvedores de jogos vem de um tempo e cultura antes de coisas assim serem difundidas e, portanto, é difícil argumentar agora que esses métodos são necessários. Isso se tornou ainda mais verdadeiro nos últimos anos, com a expectativa de que o usuário possa corrigir seu próprio software após o lançamento.

Em parte, é porque o idioma dominante no setor de desenvolvimento de jogos é o C ++ e isso torna o teste de unidade um pouco mais complicado do que outros idiomas. As estruturas de teste de unidade existem, mas não são tão fáceis de usar quanto os sistemas semelhantes em linguagens mais modernas, que podem usar reflexão e truques semelhantes para acelerar a detecção de casos de teste.

Além disso, é porque os jogos geralmente não se prestam a testes de unidade - grande parte da lógica depende de fontes semi-determinísticas (por exemplo, hardware gráfico, tempos de entrada, taxa de quadros), grande parte da produção é difícil de medir (por exemplo, gráficos na tela, efeitos sonoros) e alguns são quase sem sentido fora do contexto do jogo completo (por exemplo, IA reativa complexa, simulações de física). Existem exceções - muitas, se você trabalha duro para criar o código dessa maneira -, mas no geral os testes são mais caros em jogos do que na maioria dos outros tipos de software e, portanto, a relação custo / benefício é mais duvidosa.

Quanto aos testes de integração, nunca ouvi falar do termo ser explicitamente usado no desenvolvimento de jogos, mas muitos desenvolvedores realizam testes automatizados de todo o sistema, sempre que possível. Suponho que eu diria que talvez um em cada três desenvolvedores profissionais faça isso, pois nem sempre é fácil de configurar e porque os benefícios são reduzidos pelo fato de que praticamente todos os desenvolvedores de médio a grande porte (ou seus editores) têm um controle de qualidade departamento que executará manualmente testes semelhantes. O controle de qualidade geralmente é pago muito menos do que os desenvolvedores, portanto, pode ser considerado econômico deixar o teste para eles, em vez de investir tempo extra no código. (Controverso.)

Não vejo como escrever um jogo é diferente de qualquer outro software no que diz respeito aos testes. Cada componente do software, seja acionando um evento programado, enviando comandos para um personagem do jogo ou pressionando os botões de menu, deve ser testado para uma execução adequada.

Testar se é possível concluir o jogo é uma questão diferente e não se enquadra tanto nos testes de unidade ou integração.

Em geral, automatizar o teste da interface do usuário (mesmo em programas regulares) é mais difícil do que a automação regular. Portanto, mesmo que você possa escrever testes de unidade para seus jogos, testar o jogo real é mais difícil. A maioria das empresas usa testadores humanos que executam o jogo várias vezes.

Por exemplo, aqui está um artigo explicando como eles fazem isso em um pequeno Game Studio (2 desenvolvedores). Pelo que li, parece que sua validação não é muito detalhada (a automação inicia o jogo e registra quaisquer erros / afirmações).

No entanto, algumas empresas são bem-sucedidas com a semi-automação (como o Microsoft Test Studios). Ou seja, desenvolvedores ou SDETs constroem ferramentas que tornam o teste do jogo muito mais fácil. Houve conversas sobre a Gamefest onde eles discutem como testaram o Crackdown, por exemplo, ou o Fable. Por exemplo, eles ainda usam testadores que verificam se todos os objetos estão onde deveriam estar, mas usam uma ferramenta que tira um instantâneo desse local, para que tudo o que o humano faça seja verificar visualmente que está lá sem ter que jogar o jogo.

Aqui está uma boa conversa sobre que tipo de ferramentas eles constroem / usam para testar os jogos. Ele se chama "Test Lead Gems: saindo na frente da crescente complexidade de nossos jogos"

Eu apostaria que o código do servidor MMO e multiplayer, no entanto, é um pouco mais testado.

No mínimo, testes de regressão automatizados têm sido comuns. Eu os vi implementados como verificações de sanidade em massa durante a inicialização do servidor, por exemplo, para garantir que um novo servidor "em nuvem" foi configurado corretamente antes de começar a aceitar jogadores; um conjunto de regressão bastante bom, construído em 3 a 4 anos, nesse caso, foi executado em cerca de 4 segundos, enquanto a criação de um host virtual (a partir de uma imagem em branco do SO) demorou quase 10 minutos, por isso valeu a pena. Fizemos os mesmos testes em um "tinderbox" (sistema de compilação contínua) em nosso repositório Subversion para verificar se havia erros irritantes e razoavelmente comuns que gostavam de aparecer novamente. Em particular, a funcionalidade multi-servidor tinha o hábito desagradável de tentar crie duplicatas de objetos à medida que foram transmitidas: a instanciação, o armazenamento em cache, e o código de passagem de rede estava quase 100% coberto; continuamos pensando que tínhamos pensado em tudo o que poderia ser testado e, em seguida, descobrimos um novo caso "divertido".

Em vários MMOs em que trabalhei, também desenvolvemos "clientes stub" para realizar testes iniciais de unidade e, geralmente, fornecemos comandos "operador" para realizar testes ad-hoc de novos recursos. Isso permite executar o código do servidor antes que o cliente esteja pronto para tirá-lo vantagem e exercitar situações "impossíveis" (por exemplo, teleportar um jogador dentro de um muro) para garantir que os manipuladores de recuperação de erros funcionem bem. Colocar um novo recurso on-line no servidor às vezes pode levar muitos dias a menos do que o suporte ao cliente; por outro lado, às vezes teríamos que criar um método de servidor "fictício" para o cliente, retornando dados falsos, mas bem formados, se eles estivessem à nossa frente.

No entanto, o desenvolvimento do MMO em geral está sujeito a muito mais desses tipos de problemas, que podem refletir o ambiente. Quando eu estava trabalhando em sistemas de jogos incorporados, o "teste" era praticamente inédito para qualquer coisa, exceto algum código de widget reutilizável (por exemplo, editores de texto).

Outra razão pela qual o teste automatizado não é tão comum no Desenvolvimento de Jogos que pode ser considerado é que, para a maioria dos jogos, há muitos voluntários de teste Beta que consideram a participação no Game Beta como uma "vantagem" quando o jogo é lançado. É claro que os testes automatizados cresceram devido aos requisitos de qualidade, mas também às restrições orçamentárias. Portanto, como nos jogos existem muitos testadores experientes que estão preparados para testar gratuitamente, talvez esse seja outro motivo pelo qual os testes automatizados não são tão difundidos.

Participei de uma mesa redonda sobre testes automatizados na GDC 2011 . IIRC, havia cerca de 60 pessoas na sala. A certa altura, o moderador fez uma pesquisa sobre a cobertura dos testes de unidade. Houve uma pessoa que reivindicou mais de 90% de cobertura de código. Todos os outros riram ao pensar em alcançar 1% de cobertura. Se esse grupo é uma representação justa da indústria como um todo, eu diria que o teste automatizado geralmente não acontece muito, se é que acontece.

As outras respostas aqui dão boas razões para isso. Eu apenas pensei que seria útil ter uma conta em primeira mão.