Primeiro, eu discordo de "1) Edite seu código (de produção) e seu Teste de Unidade". Você deve modificar apenas um de cada vez, caso contrário, se o resultado mudar, você não saberá o que causou isso.
Eu gosto de colocar testes de unidade em uma árvore de diretórios que sombreia a árvore principal. Se eu tiver /sources/componentA/alpha/foo.cc
e /objects/componentA/beta/foo.o
, quero algo como /UTest_sources/componentA/alpha/test_foo.cc
e /UTest_objects/componentA/beta/test_foo.o
. Eu uso a mesma árvore de sombra para objetos stub / mock e quaisquer outras fontes que os testes precisem. Haverá alguns casos de borda, mas esse esquema simplifica muito as coisas. Um bom editor macro pode puxar a fonte de teste ao lado da fonte de assunto sem esforço. Um bom sistema de compilação (por exemplo, GNUMake) pode compilar ambos e executar o teste com um comando (por exemplo, make test_foo
) e pode gerenciar um bazillion desses processos - apenas aqueles cujas origens foram alteradas desde a última vez em que foram testados - facilmente (Eu nunca encontrei a sobrecarga de iniciar esses processos para ser um problema, é O (N)).
No mesmo framework, você pode ter testes em larga escala (não mais testes de unidade) que ligam muitos objetos juntos e executam muitos testes. O truque é classificar esses testes por quanto tempo eles levam para construir / executar e trabalhá-los em sua programação diária de acordo. Execute o teste de um segundo ou menos sempre que desejar; iniciar o teste de dez segundos e alongar; teste de cinco minutos e faça uma pausa; teste de meia hora e ir para o almoço; teste de seis horas e ir para casa. Se você achar que está perdendo muito tempo, por exemplo revivendo um grande teste depois de alterar apenas um arquivo pequeno, você está fazendo tudo errado - mesmo se a vinculação fosse instantânea, você ainda estaria realizando um longo teste quando não fosse necessário.