O que devo procurar ao avaliar ferramentas e bibliotecas de teste de unidade?

Estou no processo de escolher novas ferramentas de teste de unidade para o projeto que será iniciado em breve. Há muitos deles!

Os requisitos básicos que tenho são que ele pode executar testes em pelo menos Windows e Linux, é compatível com C ++ / C ++ 03, pode executar testes em paralelo (por exemplo, para tirar proveito de processadores com vários núcleos) e pode ser executado a partir da linha de comando. Mas esses são requisitos bastante amplos e não diminuíram o campo.

Para tentar fazer isso, estou analisando possíveis armadilhas e armadilhas de diferentes tipos de implementações. Por exemplo, se eu quisesse usar um mecanismo de teste de unidade em linguagem de nível superior como Python, ele ainda produziria saída formatada como testes de unidade C? Minha principal intenção aqui é usar as mesmas ferramentas de armazenamento e relatório para testes de resultados em C ++ e Python.

Também estou pensando se é necessário ter um mecanismo específico para executar os testes ou se é suficiente integrá-los ao nosso mecanismo de integração contínua (buildbot).

Essas duas preocupações acima são válidas? Com o que mais eu deveria me preocupar ao avaliar os mecanismos de teste de unidade?

Eu usei o Google Test e o Boost Test . Ambos são estruturas xUnit, funcionam no Unix e Windows e estão maduros. Acabei usando o Google Test devido ao Google Mock, pois também queria uma estrutura de simulação. Ou deve funcionar bem no buildbot.

Pessoalmente, quero que a estrutura de teste de unidade seja mínima e rápida. Quero muitos testes e, portanto, quero que eles sejam executados em um prazo razoável. Pessoalmente, gosto de usar a estrutura principal de uma linguagem em vez de uma mega ferramenta, mas isso é pessoal. Se você quiser, poderá analisar o teste de iteração contínuo: sempre que salvar um arquivo, ele executa automaticamente os casos de teste dos quais o arquivo depende.

Você sempre pode escrever uma classe Interface no seu teste de unidade, permitindo assim uma mudança rápida e eficaz de estruturas.

Minhas experiências envolvem CruiseControl.NET e Team Foundation Build. Sou desenvolvedor .NET. Elas vêm de minhas experiências e incluem apenas as experiências em que testamos como parte do processo de compilação; portanto, se elas não corresponderem ao seu ambiente, desculpe.

Também estou pensando se é necessário ter um mecanismo específico para executar os testes ou se é suficiente integrá-los ao nosso mecanismo de integração contínua

Se você estiver fazendo uma compilação a cada check-in, é possível que as compilações sejam acionadas antes da conclusão da compilação anterior. Como você deseja lidar com situações como essa? Por exemplo, se levar 30 minutos para executar todo o conjunto de testes e o código for verificado a cada 15 minutos, você deseja pular algumas compilações? Passar alguns testes? Empilhá-los, construí-los em ordem e voltar para Bob que ele quebrou a construção com seu check-in há 5 horas?

O Team Foundation Build pode usar vários núcleos para compilações e testes com 2010 (as versões anteriores só podiam usar vários núcleos para compilações em C ++). O CruiseControl.NET pode executar threads separados, mas ao ler a documentação , parece que cada projeto pode estar em seu próprio thread, mas que você não pode ter vários threads por projeto (posso estar errado). Nunca tivemos uma máquina com vários núcleos para compilação nos ambientes em que trabalhei, então não posso falar de quão bom / justo / ruim eles são (ou errado, eu sou).

Em um empregador anterior, incluímos scripts Python na compilação, mas não tínhamos nenhum teste configurado para testar o Python. NANT foi usado para os componentes .NET.

Também estou me perguntando se é necessário ter um mecanismo específico para executar os testes

Eu nunca tive tempo para fazer isso, mas em um empregador anterior (vendemos software "shrinkwrap"), tínhamos muitos bugs específicos do sistema operacional (e às vezes específicos do service pack), então um dos meus objetivos era configurar vários testes máquinas com sistemas operacionais diferentes (ambos 32 + 64 bits e todos os tipos de desktop e servidor Windows a partir do XP). As máquinas de compilação eram máquinas WinXP simples e mais antigas (ou virtuais), porque esse era todo o "hardware" permitido pelos gerentes. Em vez disso, todos os testes foram executados na máquina de construção. Também configuramos conjuntos de validação como coleções de testes de unidade, embora não tenham sido executados para pequenas atualizações.