Qual estrutura de teste de unidade para jogos baseados em c ++? [fechadas]

Qual combinação de ferramentas de teste você considera melhor? Dada a estrutura / biblioteca de sua escolha, você pode considerar:

• adequação para TDD
• facilidade de uso / produtividade
• lidando com objetos simulados
• configuração com integração contínua
• relatório de erros

Nota: Embora essa seja uma pergunta potencialmente genérica como a do SO, eu argumentaria que o desenvolvimento de jogos geralmente está vinculado a um fluxo de trabalho específico que influencia a escolha dos testes. Para uma perspectiva de nível superior, consulte a pergunta Teste automatizado de jogos .

Eu achei o UnitTest ++ muito fácil de trabalhar. Ainda terei que tentar amopar junto com ele, que foi mencionado como um bom companheiro para o UnitTest ++ para a funcionalidade de objeto simulado. Caso contrário, o Google Mock é uma escolha popular. Além disso, você pode ler sobre UnitTest ++ e Mock Objects .

O UnitTest ++ pode ser configurado com sua abordagem de integração contínua, por exemplo, com Hudson

Você pode ler este post inspirador se não estiver convencido de que os testes de unidade e os jogos vão bem juntos.

Outra votação para o UnitTest ++ . Muito fácil de integrar, compilado para a nossa plataforma embarcada de destino com muita facilidade, direto e fácil de usar. Também o integramos ao Hudson. Analisamos o GoogleTest, mas o rejeitamos (acho que houve problemas na compilação da nossa plataforma de destino), mas ele tem um conjunto de recursos semelhantes e pode ser adequado para você.

Além disso, você pode querer examinar algum tipo de estrutura de teste de fumaça. Na minha experiência, é difícil obter cobertura de teste suficiente para um jogo apenas com testes de unidade. Especialmente se você estiver introduzindo o teste de unidade em uma base de código existente e, mais ainda, para uma grande equipe. O teste de fumaça estaria testando coisas de alto nível como "verifique se todos os níveis carregam". Minha teoria é que, se eu tiver os dois tipos de teste, em algum momento eles poderão se encontrar no meio e dar uma média decente. :)

Quando eu trabalhava em C ++ (aviso de isenção de responsabilidade: isso era por volta de 2005), usei uma versão ligeiramente modificada do TUT (Template Unit Test Framework) . Gostei porque era muito leve, o que facilitou a modificação e significava que havia muito pouca "cola" necessária ao escrever testes.

Aqui está uma modificação muito simples que eu fiz, que torna ainda mais ávido / limpo escrever testes:

static int BogusFunction() { return __COUNTER__; } // Increment the __COUNTER__ to the correct position for the begining of the tests
#define TEST template<> template<> void object::test<__COUNTER__>()
#define ENSURE(msg, cond) ensure(msg, cond, __FILE__, __LINE__)
#define ENSURE_EQUALS(msg, actual, expected) ensure_equals(msg, actual, expected, __FILE__, __LINE__)
#define ENSURE_DISTANCE(msg, actual, expected, distance) ensure_distance(msg, actual, expected, distance, __FILE__, __LINE__)
#define FAIL(msg) fail(msg, __FILE__, __LINE__)

A outra alteração que fiz foi no formato de saída, para que as falhas de teste fossem exibidas corretamente na lista de erros do Visual Studios (quando executadas como parte de uma compilação), clicáveis ​​para ir para o arquivo e a linha do teste que falhou.

(A capacidade de fazer esse tipo de coisa significa que ela pode ser ajustada ao seu processo TDD / CI, em vez de forçá-lo a se encaixar nele .)

Aqui está um exemplo de teste (da pilha de comandos do meu editor):

TEST // Undoing a command
{
    cs.AddCommand(new TestCommand);
    cs.AddCommand(new TestCommand(od));

    ENSURE("Undo success", cs.Undo());
    ENSURE_EQUALS("Stack size", cs.size(), 2);
    ENSURE_EQUALS("Command's Undo() was called", od.undo, 1);
    ENSURE_EQUALS("Command's Redo() not called", od.redo, 0);

    ACommandStack::const_iterator it = cs.end();
    ENSURE("Command is redoable", cs.GetUndoPos() == --it);
}

(No código acima, cse odsão por módulo de acessórios, e TestCommandé um objecto simulado).

Quando se trata de C ++, tentei e usei a estrutura googletest, http://code.google.com/p/googletest/ . É simples de configurar, fácil de usar e funciona muito bem.

Não sou um desenvolvedor profissional de jogos, mas sou um desenvolvedor profissional incorporado. Talvez não exatamente como jogos, mas perto. No meu local de trabalho, usamos alguns.

Eu realmente gosto do teste do google . Ele possui todos os melhores recursos das estruturas de teste de unidade recentes, mantendo tudo em uma interface mínima e alinhada ao fluxo.

O próximo da minha lista é o Boost Test . A API do teste do Google é um pouco mais moderna que o Boost.Test, mas o Boost Test fez um trabalho incrível ao adicionar novos recursos e abandonar o paradigma CppUnit.

Eu também usei o CxxTest . É muito bem feito, mas você pode dizer que não é tão moderno quanto o Boost.Test ou o Google Test. Em particular, seu suporte para suítes de teste e acessórios é um pouco estranho.

Gosto de usar os recursos avançados, mas se você é minimalista, nunca verá a diferença entre os três. A maioria dos meus colegas ficaria feliz com uma estrutura de teste de unidade que suporta o teste de registro automático (de maneira declarativa) e possui algum tipo de macro CHECK_EQUALS (a, b).

Minha biblioteca de testes favorita é o QuickCheck http://en.wikipedia.org/wiki/QuickCheck . Existe uma versão experimental do C ++, mas parece muito pesada, mas mesmo sem uma biblioteca dedicada, os princípios são fáceis de usar.

Todas as minhas classes têm um método genArbitrary que pode gerar uma instância aleatória. Eu uso isso para testar processos invertíveis de fumaça, como carregar e descarregar. Posso gerar milhares de cenas aleatórias e verificar se várias propriedades são válidas (como a cena que eu serializo é a mesma que eu deserializo).

Ele não substitui os testes de unidade tradicionais (reduz a necessidade de muitos testes de unidade em potencial), mas é uma ótima maneira de descobrir erros e ajuda a testar a minha estratégia de alocação de memória (junto com o Valgrind). É ótimo assistir a mais de um milhão de alocações saindo do Valgrind pure :).

Eu costumava usar o CxxTest como equipamento de teste, do que eu gostava. Agora todos os meus testes são exes separados. Eu só tenho uma pasta chamada Teste, e qualquer arquivo que comece com Test_ se torna um teste. Até agora, é realmente leve e fácil de fazer testes.

Com Java, existem muitas boas bibliotecas ... Não é o caso do C ++.

Para usuários de C ++, existe uma ferramenta em cadeia do Kitware que é muito interessante:

• CMake: make tool
• CDash: ferramenta de integração contínua

Kitware escreve códigos C ++ para Ciência da Computação.

Para projetos pessoais, eu uso a biblioteca de teste da unidade Boost (na plataforma Desktop). Para integração contínua, eu uso o Hudson:

• instalação fácil no Tomcat
• scriptable

Vou testar a estrutura do TUT (Template Unit Test) ; é super leve e extremamente flexível, para não mencionar realmente fácil de configurar e usar imediatamente (um único cabeçalho inclui, um pouco de código principal / de configuração e 24 linhas de código de teste depois que você faz um teste de unidade). Eu o combinei com o binfmtc (execute programas C ++ como scripts) para obter modelos de prototipagem rápida / TDD / aprendizado com grande sucesso, incluindo desenvolvimento de software incorporado. Por ser capaz de gerar saída para XML, também se encaixou muito bem com Jenkins (CI) e Sonar em projetos sucessivos meus.