BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Manutenabilidade de Testes Unitários

Manutenabilidade de Testes Unitários

Favoritos

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?

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT