Skip to content

(Cobertura 100%) != (100% Testado)

Setembro 25, 2011

O assunto hoje é teste unitário !!

Quase sempre que converso com uma equipe de desenvolvimento, chega um determinado ponto da conversa em que o assunto é cobertura de teste unitário. Nesse momento, 80% das vezes me irrito ao perceber que a mente das pessoas está totalmente voltada para a mecânica da “coisa”: Obter 100% de cobertura nos testes através de uma ferramenta de apoio, como é o caso da Emma. Ai vem sempre meu discurso: “Galera, o importante não é obter 100% de código fonte “verdinho” (sinônimo de código coberto no Emma). O importante é cobrir todos os cenários que merecem ser testados, que possuam uma lógica que, se alterada, vai FERRAR com o sistema”. O que mais me irrita ainda, é que demora para as pessoas entenderem o que eu estou falando, as vezes tenho até que mostrar um caso de teste que comprove minhas palavras.

Para aqueles que estejam pensando que sou contra o uso de ferramentas para verificação de cobertura dos testes, por favor, não pensem. Sou totalmente a favor das mesmas. No cenário atual, onde a minoria das equipes pensam no simples teste unitário, fico feliz quando vejo alguma equipe buscando cobertura de código testado.

Meu ponto é que, muitas vezes, as pessoas ficam bitoladas na cobertura 100%, testando até métodos anêmicos e sem importância. Porém, só por verem a ferramenta acusando 100% de cobertura, as pessoas simplesmente param de raciocinar e deixam passar casos de teste que são de suma importância.

Bom, para ilustrar este cenário, vou dar um exemplo “bobo”, mas que reflete bem aquilo que disse acima.
Imagine o seguinte código e sua classe de teste, ilustrados nas figuras abaixo:

Figura 1 - Código a ser testado
Figura 2 - Código de teste

Quando acionado o plugin do Emma nesta classe de teste, temos a seguinte resposta:

Figura 3 - Indicativo de cobertura

Sim, 100% do código coberto. Óbvio, construímos dois casos de teste, sendo que cada um deles entra em um dos blocos condicionais. Entretanto, cade o teste que simula o fluxo quando os dois blocos são percorridos ? Exatamente, isso não está testado, e é de suma importância neste caso.

Imagine, por exemplo, que por um incidente, alguém esteja visualizando a classe ChiesMath e, sem querer, altera a regra do segundo bloco condicional para:

Figura 3 - Condição modificada

Executemos os testes unitários novamente e ?? Todos os testes passam e 100% de cobertura é acusado. Porém, se a entrada do método for, por exemplo, 14, o score final será 10, diferente do que seria retornado no código original, 15.
Veja ai o problema, a lógica do método foi modificada e nada de os testes unitários pegarem o erro.
Se existisse o teste unitário que simulasse o fluxo que passa por ambos blocos condicionais, certamente o teste iria quebrar ao ser executado contra a versão alterada.

Bom, é isso. Cobertura de teste É SIM legal e util. Mas por favor, não se restrinja ao label de 100% de cobertura.

From → Uncategorized

One Comment

Trackbacks & Pingbacks

  1. Os 8 erros mais comuns ao se escrever testes de unidade

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

Coding Horror

Um prato de informações tecnológicas com uma pitada de conhecimento aleatório.

InfoQ

Um prato de informações tecnológicas com uma pitada de conhecimento aleatório.

JBoss Developer Recent Posts

Um prato de informações tecnológicas com uma pitada de conhecimento aleatório.

JBossDivers

Mergulhando no Mundo JBoss

%d bloggers like this: