[Cascavel-pm] Testar módulos
Eden Cardim
edencardim em gmail.com
Quinta Fevereiro 15 12:28:43 PST 2007
On 2/15/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
> Se você consultar a wikipedia, eles definem "Test Driven
> Development", e mencionam que você deveria testar cada um dos seus
> "Use Cases", construindo pelo menos um "Test Case" (todas as
> expressões entre parêntesis levam a artigos sobre testes na
> wikipedia, links por conta do leitor).
Champs++ - Gostei da idéia... Vou usar o mesmo na minha resposta só
que minhas expressões estarão entre aspas ;)
> Objetivamente, o que você precisa testar é que o seu "Use Case"
> foi corretamente implementado. Pode fazer isso com uma sequência do
> tipo:
>
> a. Testar se o módulo pode ser encontrado, em condições de produção;
> b. Testar se o módulo pode ser importado (carregado, "loaded");
> c. Determinar se as funcionalidades esperadas do seu módulo estão
> no lugar;
> d. Exercitar cada uma das funcionalidades oferecidas, com pelo menos:
> I. Um teste bem-sucedido (entrada conhecida, resposta conhecida);
> II. Um teste mal-sucedido (entrada declaradamente ruim, erro
> esperado e conhecido);
> III. Um teste vazio (nenhuma entrada, erro esperado e conhecido).
>
> Isto dá uma média de 4*N+2 testes, com N sendo o número de
> funcionalidades que você implementou.
Seguir esse roteiro que você mencionou aí na vida real, não é tão
simples quanto parece, principalmente pros casos de falha. Por
exemplo, outro dia eu estava escrevendo um gerenciador de arquivos
temporários, e me deparei com o desafio de testar um caso de falha na
abertura de um arquivo temporário. São inúmeros os casos que não são
(viavelmente) reprodutíveis num teste: falha física do dispositivo de
armazenamento, falta de espaço, permissões e coisas do gênero.
Por isso eu me atenho a testar inicialmente os casos de uso
diretamente visíveis ao "mundo externo". Se algo nas entranhas do
sistema parar de funcionar, a falha provavelmente vai ser refletida em
alguma funcionalidade no perímetro do sistema. Claro que tem as falhas
que não são tão óbvias e vão escapar, mas se os seus prazos e
requisitos de qualidade são muito rigorosos, você vai precisar de
consultoria especializada (e cara) :). Ou então libera o código pra
comunidade que os patches virão naturalmente.
Os defensores do Agile Development dizem que os testes deveriam ser
escritos antes do código. No caso do Iberê, recomendo usar
Devel::Cover e tentar fechar no mínimo 90% de cobertura, usando as
dicas do Champs. Ah, e sempre que aparecer um bug (e vão aparecer
muitos, já que você não tem teste algum), escreva um teste simulando o
erro antes de tentar corrigir.
Nossa, que tratado! Nunca discutam sobre engenharia de software se não
quiserem me ver tagarelando. ;)
--
Eden Cardim
Instituto Baiano de Biotecnologia
Núcleo de Biologia Computacional e Gestão de Informações Biotecnológicas
Laboratório de Bioinformática
--
"you seem to think that 'close enough' is close enough...
please learn to be 'literal' around programming."
merlyn - on irc.freenode.net#perl
Mais detalhes sobre a lista de discussão Cascavel-pm