Você pode estragar sua aplicação pensando apenas em cobertura no Sonar!

Quantos desenvolvedores realmente entendem o quanto é importante fazer o mínimo para que sua aplicação seja um pouco confiável? Atualmente o desenvolvimento de software tem tornado-se cada vez mais desafiador e por muitas vezes complexo. Nós, desenvolvedores de software, enfrentamos diariamente o desafio de escrever boas soluções, mas com isso vem a complexidade e problemas gerados pelos códigos que escrevemos.

Um ponto muito comum entre a comunidade de software é a escrita de testes de unidade que ajudam a deixar o código minimamente confiável para sofrer alterações e eventuais manutenções que são realmente necessárias. Segundo Mike Cohn em seu livro Succeeding with Agile, podemos ter uma pirâmide de testes no qual a base ou seja o fundamento seria o teste de unidade, camada mais barata por ser rápida e mais isolada.

É muito comum a escrita de testes de unidade, no entanto, não são todos os desenvolvedores que entendem a importância de escrever bons testes unitários. Por isso, há muitos projetos em que os desenvolvedores são obrigados a ter uma cobertura mínima de testes para subir o software até produção, mas existem várias formas de mascarar essa cobertura. Veja alguns exemplos abaixo:

Exemplo de sonar com alta cobertura de testes

Na imagem acima podemos ver que o percentual de cobertura de testes de unidade está consideravelmente alto com 96.6%. Porém nesse projeto existem vários testes "mascarados". Veja a próxima imagem:

Exemplo de uma classe com testes unitários mascarados

Repare na imagem acima que as linhas 22 a 26 estão marcadas como cobertas no Sonar, entretanto, ao rodar um teste de mutação é fácil identificar um problema. Pois, na hipótese de um desenvolvedor remover as linhas marcadas em vermelho, o teste unitário escrito para essa funcionalidade continuará passando. Desta forma, não cumprirá o seu objetivo principal: avisar quando alguma alteração na lógica estiver sendo feita. Veja a imagem abaixo para entender melhor:

Relatório do PiTest mostrando a força baixa dos testes de unidade

Nesse relatório podemos perceber que a coluna Line Coverage(linha coberta) até está com o percentual alto, que é exatamente o que podemos ver no Sonar quando escrevemos os testes em nossas aplicações, entretanto na coluna Mutation Coverage(cobertura por mutação) está bem baixa mostrando o quanto a força dos testes unitários está baixa e por consequência temos uma alta cobertura "mascarada" de qualidade.

Portanto é possível afirmar que podemos estragar a nossa aplicação quando pensamos apenas em cobertura de código que é visto em um relatório do Sonar. A responsabilidade de criar códigos com qualidade é do desenvolvedor de software, segundo o Uncle Bob "se todos deixássemos nosso código mais limpo do que quando começamos, ele simplesmente não degradaria" usando a regra de escoteiro(deixar o código melhor do que quando o encontramos). Levando isso para a escrita de testes de unidade, busque sempre deixar o software mais confiável criando testes sem mascarar o Sonar e seja feliz de verdade.

Quer saber mais sobre? Veja a playlist abaixo:

Espero que curta e nos vemos em meu próximo artigo.