Como o código de Teste de Unidade C ++ deve ser organizado para a eficiência máxima do Teste de Unidade?

• Esta questão não é sobre as estruturas de teste de unidades.
• Esta questão não é sobre como escrever Testes Unitários.
• Esta questão é sobre onde colocar o código UT escrito e como / quando / onde compilá-lo e executá-lo.

Em Trabalhando efetivamente com o Código Legado , Michael Feathers afirma que

good unit tests ... run fast

e que

A unit test that takes 1/10th of a second to run is a slow unit test.

Eu acho que essas definições fazem sentido. _{Eu também acho que eles implicam que você tem que manter um conjunto de Testes de Unidade e um conjunto de Os Testes de Código que Demoram Mais separadamente, mas eu acho que é o preço que você paga por apenas chamar algo de um Teste de Unidade se ele for executado (muito) rápido.}

Obviamente, o problema em C ++ é que para "executar" seu Teste de Unidade ( s ), você precisa:

1. Edite seu código (produção ou teste de unidade, dependendo de qual "ciclo" você está)
2. Compilar
3. Link
4. Iniciar o executável de teste de unidade ( s )

Editar _{(depois de uma votação estranha)} : Antes de entrar nos detalhes, vou tentar resumir o ponto aqui:

Como o código de Teste de Unidade do C ++ pode ser organizado de forma eficaz, de modo que seja eficiente editar o código (teste) e executar o código de teste?

O problema primeiro é então decidir onde colocar o código do Teste de Unidade para que:

• é "natural" editá-lo e visualizá-lo em combinação com o código de produção associado.
• é fácil / rápido iniciar o ciclo de compilação para a unidade que está sendo alterada no momento

O segundo problema relacionado, então, é o que é compilado para que o feedback seja instantâneo.

Opções extremas:

• Cada Unit-Test-Test-Unit vive em um arquivo cpp separado e esse arquivo cpp é compilado + vinculado separadamente (junto com o arquivo de unidade de código-fonte testado) para um único executável que executa este Teste Unitário.
  • (+) Isso minimiza o tempo de inicialização (compilação + link!) para a única Unidade de teste.
  • (+) O teste é executado super rápido, porque ele testa apenas uma unidade.
  • (-) A execução de todo o conjunto precisará iniciar um bazillion de processos. Pode ser um problema para gerenciar.
  • (-) A sobrecarga de processos começa a ficar visível
• O outro lado seria ter - ainda - um arquivo cpp por teste, mas todos os arquivos cpp de teste (junto com o código que eles testam!) são vinculados em um executável (por módulo / por projeto / escolha seu escolha).
  • (+) O tempo de compilação ainda seria OK, pois somente o código alterado será compilado.
  • (+) A execução de todo o pacote é fácil, pois há apenas um exe para ser executado.
  • (-) A suíte levará tempo para vincular, pois cada recompilação de qualquer objeto acionará um novo link.
  • (-) (?) O processo levará mais tempo para ser executado, embora se todos os Testes de Unidade forem rápidos, o tempo deve ser OK.

Então, como são tratados os Testes de Unidade de C ++ do mundo real? Se eu só executo esse material todas as noites / horas, a segunda parte realmente não importa, mas a primeira parte, como "acoplar" o código UT ao código de produção, para que seja "natural" que os desenvolvedores mantenham ambos em foco sempre importa, eu acho. (E se os desenvolvedores tiverem o código UT em foco, eles vão querer executá-lo, o que nos traz de volta à segunda parte.)

Histórias do mundo real e experiência apreciada!

_Notas:

• _{Esta questão deixa intencionalmente a plataforma não especificada e o sistema make / project.}
• _{Perguntas marcadas como UT & C ++ é um ótimo lugar para começar, mas infelizmente muitas perguntas, e especialmente as respostas, estão muito concentradas nos detalhes ou em estruturas específicas.}
• _{Há algum tempo, eu respondi a um pergunta semelhante na estrutura para testes unitários de reforço. Eu acho que esta estrutura está faltando para testes unitários "reais" e rápidos. E eu acho a outra questão muito estreita, daí esta nova pergunta.}