Dherik Barison
Aug 2, 2018 · 2 min read
“Programming” by Fredrik Walløe

Uma boa prática conhecida (mas nem sempre aplicada) dentro do desenvolvimento de software é a de fazer testes unitários para cada bug encontrado no sistema.

O processo funciona mais ou menos assim:

  1. Identificar onde o bug ocorre;
  2. Fazer um teste para reproduzir o bug;
  3. Fazer a correção do bug;
  4. Verificar se o teste passa após a correção do bug.

Contudo, há vários questionamentos com relação a esta atividade:

  • Não é um exagero fazer isto para cada bug?
  • E se o cenário para reproduzir o bug for difícil?
  • E se o erro for oriundo de uma consulta ao banco de dados?

Entre outras perguntas.

Acredito que fazer um teste unitário para cada bug encontrado não é um dever ou obrigação, mas algo que os desenvolvedores deveriam considerar como uma boa prática para melhorar a qualidade das entregas.

Para saber quando fazer, é preciso entender o cenário do bug. E quando digo cenário, não falo apenas do código envolvido, mas também do estado atual do seu projeto. Vamos lá então.

Se a reprodução via teste unitário é simples de ser feita, não vejo desculpas para não o fazer: você reproduz o problema no teste, realiza a correção e garante que o mesmo bug não voltará. São muitas vantagens para ignorar :).

Já se a reprodução for mais complexa, temos que verificar qual a severidade do bug, a complexidade de fazer e manter o teste, da probabilidade dele ocorrer novamente e confrontar a criação deste teste com as outras deadlines do seu projeto. Não raro temos bugs no código que são simples de resolver, mas muito complicados de se reproduzir em um teste. Perder um tempo considerável fazendo um teste, sendo que o projeto tem outros problemas pedindo sua atenção, pode ser uma má escolha.

Bugs envolvendo regras de negócio merecem um capítulo à parte. Como eles fazem parte do core do seu projeto e são mais propensos a quebrar no futuro, eles são quase sempre fortes candidatos a receberem um teste.

O teste para reprodução do problema também pode envolver a criação de testes de integração¹, podendo cobrir problemas em consultas ao banco de dados, garantir que a injeção de dependências das suas classes está correta, se a sua API está aceitando o contrato correto, etc.

Em geral, na maior parte das vezes é viável criar um teste para cada bug encontrado. Portanto, avalie a situação e pense com carinho em criar um teste para o próximo bug do seu projeto.

¹. Como este termo pode ter diferentes entendimentos, estou adotando o conceito de narrow integration tests do Martin Fowler.

CWI Software

Desenvolvemos soluções e sistemas de TI com base nas necessidades específicas de empresa de médio e grande porte em âmbito global, desde 1991.

Dherik Barison

Written by

Java developer, Tech Lead, Stack Overflow enthusiast and contributor: https://dherik.com

CWI Software

Desenvolvemos soluções e sistemas de TI com base nas necessidades específicas de empresa de médio e grande porte em âmbito global, desde 1991.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade