Os geradores de teste de unidade o ajudaram a trabalhar com código legado?

Eu estou olhando para uma base de código pequena (~ 70kLOC incluindo C # gerada) (.NET 4.0, alguns Silverlight) que possui uma cobertura de teste muito baixa. O código em si funciona porque passou no teste de aceitação do usuário, mas é frágil e, em algumas áreas, não é muito bem fatorado. Eu gostaria de adicionar uma cobertura sólida de teste de unidade em torno do código legado usando os suspeitos do costume (NMock, NUnit, StatLight para os bits do Silverlight).

Minha abordagem normal é começar a trabalhar no projeto, teste de unidade e refatoração, até que eu esteja satisfeito com o estado do código. Eu fiz isso muitas vezes no passado e funcionou bem.

No entanto, desta vez, estou pensando em usar um gerador de teste (em particular o Pex ) para criar a estrutura de teste e, em seguida, aprimorá-la manualmente.

Minha pergunta é: você já usou geradores de teste de unidade no início do trabalho em uma base de código herdada? Em caso afirmativo, você os recomendaria?

Meu medo é que os testes gerados não atinjam as nuances semânticas da base de código, levando à terrível situação de ter testes para a métrica de cobertura, em vez de testes que expressam claramente o comportamento pretendido no código.

unit-testing legacy

— Duncan Bayne
fonte

Eu tentei o PeX uma vez e os resultados foram, digamos, pouco satisfatórios - YMMV. Não espere que essa ferramenta "entenda" seu código e seus requisitos funcionais - ela não perde apenas as "nuances semânticas", perde toda a semântica. Além disso, quando você inicia com uma base de código herdada, normalmente não inicia primeiro com os testes de unidade, mas com os testes de sistema ou de integração; definitivamente não é para isso que o PeX foi criado.

— Doc Brown

Eu sugeriria olhar as coisas um pouco diferente. Adicionar novo código de teste de unidade a um aplicativo existente sem incidentes pode não fornecer os melhores resultados. Se você estiver fazendo isso para se familiarizar com a base de código ou se realmente tiver tempo para matar e quiser testar os geradores de teste, ignore meus comentários.

Para ser pragmático, você deve examinar todas as listas de erros. Em seguida, crie testes de unidade para cada um dos erros, resultando em como ele deve se comportar. Idealmente, você adicionaria apenas um novo código para cada bug à medida que o alcançasse.

Tempos para adicionar código de teste de unidade:

Adicionando nova funcionalidade
Código refatorado
Corrigido um bug
Aprendendo o que o código faz
Prove que um bug existe

É difícil quantificar o valor da adição de testes de unidade após o fato.

Normalmente, não me permito escrever respostas contrárias ao que o solicitante deseja, mas acho que essa é uma boa lição para passar adiante.

— Andrew T Finnell
fonte

Estou 100% de acordo com você lá - essa pergunta surgiu de mim, imaginando a melhor maneira de passar algum tempo de inatividade. Minha prática normal é testar e refatorar no processo de correção de bugs ou adição de recursos. Eu estava esperando que algumas pessoas podem ser capazes de compartilhar algumas de guerra histórias nesta área ...

— Duncan Bayne

+1, fotografar para cobertura após o fato geralmente não é produtivo. Ter testes em bugs corrigidos que impedem a regressão é muito produtivo. A regressão de um bug pode ser muito frustrante para todos os envolvidos. Os testes são realmente adequados para ajudá-lo a escrever um código melhor. Aparafusar testes geralmente resulta em testes abaixo do padrão. Acho que o medo do OP está fundado e a relação sinal / ruído dos testes gerados apenas atrapalha. O código não testado provavelmente possui alguns bits muito ramificados. Ferramentas que apontam o cheiro do código são provavelmente mais úteis. Talvez FXCop e ferramentas similares.

— kevpie