[Cascavel-pm] Testar módulos

[Eden Cardim]

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