[Cascavel-pm] Testar módulos

Marco Aurélio MACAÉ interativa em pcp.org.br
Quinta Fevereiro 15 16:37:26 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. ;)
> 





Boa noite, Caros irmãos em Perl Mongers,

Concordo com vocês! Portanto eu gostaria de acrescenta que uma 
aplicação, web e/ou desktop não tem só erros técnicos, mais também tem 
erros de composição, usabilidade, modelagem e consistência, 
marketing... Geralmente os erros são encontrados durante a versão 
beta, e o processo de evolução não para, de versão em versão, vai 
evoluindo, com muito zelo, tempo, paciência e persistência, o retorno 
será uma aplicação que sempre amadurece... Eu sei que estou fora do 
contexto, pois o Luis e Eden Cardim falam apenas dos testes de erros 
técnicos. È muito importante acolher os questionamentos dos usuários, 
bem como acompanhar os relatórios de testes e erros técnicos da 
aplicação! 

Fraternalmente em Perl Mongers,
Marco Aurélio (MACAÈ)
Bloco dos Perl Mongers do Recife (PE)
“100 anos do Frevo – 1907 a 2007 – Olinda e Recife (PE)”






> -- 
> 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
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
> 
> 

-- 



Mais detalhes sobre a lista de discussão Cascavel-pm