Tenho publicado uma série de posts sobre testes unitários nas últimas semanas, quem acompanha o blog certamente notou…pois bem, os testes estão indo de vento em poupa.

Neste post pretendo encorajar aqueles que precisam ouvir boas experiências com este tipo de abordagem bem como tentar deixar bem claro alguns limites nestes testes.

Se você começou a escrever testes unitário agora, você deve estar se fazendo uma série de perguntas, seus testes podem parecer um pouco sem sentido, repetitivos e em algum momento você vai ter que ir no ‘pai google’ procurar respostas, boas práticas e dicas.

Pois bem, comigo não foi diferente, visitei inúmeros sites, li e escutei várias opiniões…e foram delas que alinhei minhas expectativas, aprumei o rumo e segui em frente…para o alto e avante!

Perguntas do tipo:

i. Qual a vantagem desta abordagem?;
ii. Posso testar todo o sistema usando esta abordagem?;
iii. Meus testes são confiáveis?;
iv. Quais os meus limites? Onde começo? Onde paro?

Você fará quando começar a por a mão na massa, tentarei expor minas opiniões sobre elas, a seguir…

i. Qual a vantagem desta abordagem?

Bug custa caro!

Todos nós engenheiros de teste sabemos…se não sabem, deveriam saber!…quanto mais tarde no ciclo de vida de um software um bug é encontrado, mais caro ele se torna. Um bug achado durante a especificação pode custar $1 para corrigir…$10 se achado no design…$100 se achado na implementação…$1000 na entrega do produto.

A idéia por trás dos testes de unitários é achar bugs mais cedo, quando um bug é achado nos testes unitários, corrigi-lo é trivial, pois o desenvolvedor está com lógica de seu código ainda fresca em sua mente, mas também não adianta nada achar bugs saídos do forno, se sua equipe não corrige o bug antes de produzir novos códigos, dêem uma lida no trecho retirado do blog Joel on Software.

[...]The very first version of Microsoft Word for Windows was considered a “death march” project. It took forever. It kept slipping. The whole team was working ridiculous hours, the project was delayed again, and again, and again, and the stress was incredible. When the dang thing finally shipped, years late, Microsoft sent the whole team off to Cancun for a vacation, then sat down for some serious soul-searching.

What they realized was that the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”[...]

Ou seja, se sua equipe, gerentes e/ou líderes técnicos, não dedicarem o tempo de sua equipe para a correção de bugs achados durante esta fase, nada vai dar certo, portanto, antes de começar a escrever testes unitários converse com eles, mostre-os a vantagem de adotar esta abordagem, na maioria das vezes os gerentes de projeto gostam desta idéia.

ii. Posso testar todo o sistema usando esta abordagem?

Não!

Nem comece a implementar se você acha que 100% de seus testes vão ser unitários, uma aplicação precisa de uma atenção bem especial na sua interface, não é lá que estão a maioria dos bugs mas ali tem muito bug sim!

No caso do MVC com .NET (padrão muito comum em aplicações WEB com .NET) desenvolvedores costumam usar muito o codebehind para fazer validações, que muitas vezes deveriam ser feitas no controlador, pois é lá que deve conter o ‘core’ de sua regra de negócio, mas mesmo assim existem validações pequenas que devem ser feitas na view, e isso deve ser testado na interface.

Existem ferramentas com o propósito de automatizar testes no codebehind, NUnitAsp é um exemplo, mas isso eu pessoalmente não recomendo, pois você pode cair no vício de nunca na sua vida olhar pra a cara de seu produto, enfim, acho que o que está no codebehind, deve ser testando na própria interface.

iii. Meus testes são confiáveis?

Sim…e Não!

Cometemos muitos erros logo no início, não sabemos o que testar e por várias vezes ficamos bem confusos quanto ao escopo dos testes, quando falo ‘Sim, são confiáveis’ digo porque acredito que você sabe fazer seu teste funcionar, quando digo ‘Não, não são confiáveis’ digo porque inicialmente você pode estar testando o que não deve.

Teste o comportamento, não o método.

O que devemos estar preocupado é o com o comportamento do método no contexto da aplicação, certo? então tenha a certeza que o método que você está testando se comporta da forma esperada, apenas isso.

Teste métodos públicos, esqueça os privados.

Métodos privados geralmente compõem um objeto e não devem ser diretamente testados.

Estes dois exemplos foram o que me veio a mente, posteriormente publicarei minhas lições aprendidas na implementação de testes unitários.

iv. Quais os meus limites? Onde começo? Onde paro?

Não escreva testes pra todos os métodos existentes no código, existe um limite muito bem definido neste caso, se limite aos cenários que serão amplamente utilizados pela aplicação e se o custo de implementar um teste for alto, não implemente.

Testes devem ser simples, secos e ásperos, nada de códigos mirabolantes no seu teste, se ele estiver assim está errado.

Bem, por enquanto é só, espero ter ajudado com este post, posteriormente estarei postando sobre minhas experiências na implementação dos testes, boas práticas e dicas, qualquer coisa é só comentar!

comentários

leia mais...

• Testes Unitários com csUnit
• Estimando Esforço de Automação
• Testes Unitários com componente do .NET
• Template de Relatório de Testes do VS
• Executando Testes com o MSBuild