"Testar ou não" não é a questão.

sexta-feira, 23 de abril de 2010

É até engraçado ouvir de um desenvolvedor iniciante que "está pronto, só falta testar".

As chances de um código não funcionar de primeira para todos os casos previstos é tão grande que ninguém diz uma coisa destas. Se não testou, não está pronto.




Bom, para os que estão pensando em comentar sobre a declaração do Knuth dizendo que só precisa de testes automatizados quando não está desenvolvendo num ambiente familiar, onde ele já sabe o que vai e o que não vai funcionar. E eu repito o que reverberou por aí depois da declaração dele: "-Se você for o Knuth, escreva certo de primeira. Se não for, teste!".

Bom, nem era exatamente sobre isso que eu ia falar, mas antes de começar eu gostaria de dizer que só agora estou percebendo que o título fez uma rima besta. Me desculpem. Agora vai ficar assim mesmo. :-P

Como eu dizia, a questão não é sobre testar ou não. É sobre o que ou como testar.

Vou contar um caso interessante. Imaginem um projeto de alguns anos de desenvolvimento. Bom, no início tem pouco código, pouca funcionalidade e no fim de uma iteração já se põe o analista a testar manualmente. Em 2 dias está tudo testado, os bugs foram reportados, os desenvolvedores corrigiram, tudo foi revisado e o sistema está ok.

Passam-se mais alguns meses (e algumas iterações) e então são 2 dias pra testar, mais alguns pra corrigir, outros para retestar e facilmente já se foi mais de uma semana. E não dá para ser assim. Então o que o gerente esperto diz?

"-Corrijam mais rápido!"
"-Façam hora extra!"

E alguns meses depois já são duas semanas de testes. As correções se limitam aos bugs impeditivos (se tem outra forma de conseguir a mesma funcionalidade, não se perde tempo corrigindo o bug). A equipe está exausta. E o que o gerente esperto diz?


"-Corrijam mais rápido!"
"-Façam hora extra!"
"-COMO ASSIM APARECEU BUG NOVO AO CORRIGIR UM? ASSIM NÃO DÁ, PRESTEM ATENÇÃO!"

Bom, a situação foi ficando insustentável. Pessoas boas deixaram a equipe, etc...

A questão de como testar é simples. Testes automatizados. Há ótimos frameworks de testes automatizados em várias linguagens para facilitar a construção destes. Em segundos ou minutos é possível testar módulos ou sistemas inteiros. Também há testes de carga/performance que sem automatização são impossíveis.

Sugiro escrever testes automatizados em qualquer sistema minimamente sério ou complicado. A área de testes é muito vasta e há várias classificações e formas de testar. Sugiro ler Teste de Software como um ponto de partida para se saber o que aprender sobre testes. Um bom profissional na área de desenvolvimento de software deve ter uma boa noção de como ter uma segurança mínima no que foi desenvolvido. E testar é uma ferramenta poderosa para isto.

É claro que se você faz um teste para ver se o que você fez funciona, o teste não vai dizer se você desenvolveu o produto certo (validação), apenas se você desenvolveu certo o produto (verificação).
No entanto, se você já escreve seus testes tendo em vista os requisitos que precisam ser atendidos e depois escreve código que passa nestes testes, como no Test Driven Development (e talvez este seja o link mais importante de todo o post - se você só for ler um e não conhecer este, é este que deve ser lido), você já está num caminho mais maduro de desenvolvimento de código, focado nas necessidades e não na predição de possíveis problemas que mina a qualidade do código e do sistema em geral.

O que testar já varia em função do sistema que está sendo desenvolvido e do ambiente utilizado para testá-lo. Por exemplo, não faz sentido rodar teste de carga com múltiplos usuários numa administração de sistema web feito para apenas um usuário/administrador.
Da mesma forma, testar código criado automaticamente apenas para dizer que seus testes tem 100% de cobertura diz muito pouco ou nada sobre quão bem seu software está bem testado. Em geral, testar código criado automaticamente é esforço jogado fora. Esforço que o seu cliente está pagando.

Sempre é muito importante ter em mente o custo/benefício de se escrever teste para determinado trecho de código.

Mais para a frente pretendo escrever mais detalhes e dar alguns exemplos, por hoje fica aqui este artigo introdutório apontando apenas alguns links para os inciantes nesta prática se orientarem.

Quem estiver interessado em aprender mais sobre Test Driven Development (TDD) pode se aprofundar um pouco aqui: http://improveit.com.br/xp/praticas/tdd


Abraço a todos!

Bookmark and Share

Nenhum comentário:

Postar um comentário

 
addthis_config = { data_ga_tracker: pageTracker }