BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Manutenabilidade de Testes Unitários

por Lucas Souza em 26 Fev 2010 |

Recentemente o Jay Fields postou em seu blog sobre a manutenabilidade de testes unitários. Muito fala-se que testes unitários as vezes podem atrapalhar a manutenção e a adição de novas features na aplicação. Embora mudanças que, por exemplo, não alterem a interface de um método não impactem tanto nos testes, algumas vezes tem-se que fazê-las e isso causa um grande esforço na manutenção e correção dos testes.

Fields diz com base em suas experiências, que apenas 15% do tempo é gasto nas mudanças do código, enquanto os outros 85% são gasto na manutenção ou correção dos testes unitários:

Na minha opinião, fazer mudanças na interface frequentemente leva de 15% à 20% do tempo, enquanto mudanças associadas a testes levam os outros 80% à 85%.

Ele lança a seguinte questão: Eu devo escrever testes unitários?

Deve-se seguir sempre o bom senso, existem situações que realmente não são passíveis de realização de testes. Ele cita uma frase do livro Refactoring do Martin Fowler:

A chave é testar as áreas que você está mais preocupado se algo acontecer de errado. Desta maneira você ganha mais benefício com seus testes.

Um exemplo clássico de testes que as vezes são feitos e não fazem sentido é: Em um cadastro de funcionário no sistema, o nome do mesmo só pode conter caracteres alfanuméricos. Com uma simples validação no sistema resolvê-se este problema. Isto não implica que deve-se escrever um teste unitário para cada uma destas validações.

Talvez o ideal seja avaliar o grau de complexidade da funcionalidade e daí sim escrever um teste unitário para ela. E tentar ao máximo escrever testes mais concisos, ou seja, testes que com poucas linhas de código explicite o que realmente o método deve fazer. Quanto mais longo for o teste, mais fácil a chance dele ser ignorado.

Fields também cita maneiras de tornarmos o código do teste mais interessante e mais conciso:

Existem diversos métodos para criar testes concisos. Você pode usar frameworks que foquem na simplicidade, tais como Mockito. Mas, o mais importante aspecto de criar testes concisos é ter foco na modelagem de objetos. Remover construtores e argumentos de métodos é frequentemente a maneira mais fácil de reduzir a quantidade de ruído de dentro de um teste.

E você leitor? Acha que devemos escrever testes para absolutamente tudo? Testes desnecessários podem se tornar um problema?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Bom senso para testes by jefferson moreira

Testes para tudo realmente é complicado depois de manter e infelizmente acabam sendo ignorados pelos desenvolvedores em um futuro próximo. Já trabalhei em alguns projetos onde escrevemos teste para tudo e hoje ninguém mais mantem aquilo tudo de testes. Acho q é legal testes para o domínio do sistema, porém já vi gente defendendo testes em controladores também, meio complicado depois manter isso.

Métricas by Alex Egidio

Penso que não é necessário e não é recomendado fazer testes para tudo. Devemos lançar mão das métricas, os cálculos de complexidade, etc que podem nos apontar quais os trechos mais críticos dos nosso código e que devem ser realmente testados.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT