Abordagem de teste de unidade errada

Question

Abordagem de teste de unidade errada

#1 resposta do (4 votos)

5

Minha organização está investindo tempo escrevendo os tipos errados de testes (testes de unidade que estão muito atrelados à implementação, são muito demorados para criar, e muitas vezes tornam o sistema mais difícil de mudar). Além disso, o contexto é muitas vezes jogado fora e os testes são distorcidos para melhorar as métricas de cobertura.

As mesmas suposições incluídas no código são incorporadas aos testes unitários.

Acredito que a cobertura de código é uma métrica enganosa. Um pode ter cobertura de código de 100% e ainda ter muitos bugs, muitos casos de borda não testados, etc. O custo de quanto trabalho leva para obter os últimos 10% de cobertura não fornece valor de venda.

Os testes não servem bem como "especificações legíveis" (um ideal que soa bem no papel, mas que muitas vezes não traduz).

Eu encontrei um teste que, por exemplo, afirmou que um determinado menu suspenso "contém 7 itens". Isso não é mapeado para nenhuma expectativa do mundo real mantida por usuários de negócios ou até por pessoas técnicas. Parece que o autor desse teste estava apenas procurando "algo para afirmar".

Eu temo que estejamos medindo o que é fácil de medir sobre o que é importante (embora talvez menos mensurável).

Alguns dos testes são escritos em um nível tal que eles configuram mocks para verificar cada minúsculo passo da implementação (foi Dispose chamado no UnitOfWork)? Etc.

Eu preferiria testes baseados em resultados - verificar se o resultado está correto, o "o quê" e não o "como".

Eu acho que seria ótimo fazer BDD ou ATDD (desenvolvimento orientado a testes de aceitação), mas organizacionalmente não estamos prontos para uma grande mudança de paradigma para Pepino ou SpecFlow ou uma ferramenta semelhante (embora talvez seja um bom objetivo a longo prazo) .

Aqui está o problema. Se você expressar o desejo de escrever menos testes, o teste zeloso olhará para você como se tivesse se revelado profundamente ignorante / imoral. Talvez eu esteja projetando um pouco? Mas ninguém quer soar como eles estão sugerindo que nós "cortamos cantos" para velocidade. No entanto, acho que nosso processo é arrastado pela adesão cega a protocolos que nem sempre são contextualmente apropriados.

Existe uma postura "pós-fanatista" em testes que eu posso começar a nos direcionar?

testing unit-testing

por blaster 21.06.2017 / 16:50

fonte

1 resposta

Tags testing unit-testing

Associações muitos-para-muitos em microsserviços Quando o código do cliente pode saber sobre implementações de padrão de estratégia?

score 4 · Answer 1

Não, você não é louco. Os testes de unidade / TDD são ótimos, mas devem ser aplicados corretamente.

Existe um fenómeno chamado codificação / arquitectura de cultos de carga. É quando você aplica uma abordagem sem saber por que está fazendo isso. Este parece ter sido o caso com testes automatizados em seu projeto.

Para mim,

Testes de Integração Automatizada têm usos, no entanto, o foco nos testes de unidade deve ser preferido sempre que possível.
Baseado em código Automatizado Testar a interface do usuário é uma perda de tempo. (Não estou me referindo a um framework de teste como o Selenium, que pode ser útil)
Qualquer teste que seja mais complexo que o código que está testando é apenas outro possível ponto de falha e, portanto, na melhor das hipóteses, um desperdício de tempo

O tipo de coisa a que você está se referindo está acontecendo em seu projeto é um sintoma do seguinte:

código totalmente acoplado
Falha ao isolar a lógica de negócios dos componentes de infraestrutura da base de código

Se o código fosse menos acoplado, apenas um mínimo de zombaria seria necessário.

Se a sua lógica de negócios estivesse adequadamente isolada, seria muito óbvio como escrever testes de unidade eficazes e produtivos de sua base de código.