[Cascavel-pm] Testar módulos

[Luis Motta Campos]

On Feb 15, 2007, at 12:52 AM, Iberê O. Kuntz de Souza wrote:
> Fala pessoal..

   Grande Iberê!
   Olha, antes de mais nada, quero sua chave pública. Algum lugar  
onde eu posso pegar?

> bom, eu sei que existem vários módulos para testes de outros módulos
> (Test, Test::Simple, Teste::More, Test::Harness, etc).. eu já entendi
> bem o que fazer, porém tem uma única coisa que me faz não escrever os
> testes.. eu não sei o que testar. Eu só quero saber o que devo  
> testar em
>  meu(s) módulo(s). Se alguém puder me ajudar, agredeço desde já.  
> Obrigado.

   O quê testar é uma pergunta capiciosa... :-)
   A resposta curta seria "tudo".
   Claro, esta não ajuda muito.

   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).

   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.

   Se você tem algum tipo de depósito de dados (base, arquivo, SOAP,  
qualquer coisa) envolvido no seu processo, ou algum outro tipo de  
serviço externo, pode exercitar que as respostas obtidas deste  
serviço pelo seu módulo contém dados no formato esperado (use  
Test::Deep).

   Acho que o básico para testes de unidade é isso.
   Depois, quando você tiver implementado todos estes, conversamos  
sobre os testes de integração, envolvendo a forma como diferentes  
módulos conversam entre si...

   Putamplexos!
--
Luis Motta Campos is a software engineer,
perl fanatic evangelist, and amateur {cook, photographer}