[Cascavel-pm] Testar módulos

Luis Motta Campos luismottacampos em yahoo.co.uk
Sexta Fevereiro 16 01:19:31 PST 2007


On Feb 15, 2007, at 9:28 PM, Eden Cardim wrote:
> On 2/15/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
>> (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 ;)

   Olha, que eu vou começar a cobrar Royalties... ;-)

> [roteiro sugerido para a elaboração de testes]
> Seguir esse roteiro que você mencionou aí na vida real, não é tão
> simples quanto parece, principalmente pros casos de falha.

   Bom, na verdade, se o roteiro de testes não for simples de seguir,  
certamente você tem problemas com o desenho dos seus testes. Segue  
lendo, que eu vou mostrar onde você está falhando logo abaixo:

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

   Você sempre pode usar o Mock (consulte design patterns para os  
detalhes), um objeto, serviço ou estrutura de dados que você vai usar  
como se fosse o seu caso de problemas, para determinar o que acontece  
com seu arquivo.

   Você está deixando o seu gerenciador de arquivos "tocar" seu  
sistema de arquivos durante os testes, o que não é mau, mas pode não  
ser o mais simples. Você poderia ter um FileSystemMock no lugar do  
seu sistema de arquivos original, de modo que todos os serviços  
solicitados para o sistema de arquivos "falhassem" da forma correta,  
do ponto de vista do seu gerenciador de arquivos temporários.

   O seu problema é de desenho de teste, você não está isolando  
corretamente o sistema em teste, está permitindo que ele interaja com  
uma parte "real", difícil de falhar, do ambiente. Isso não ajuda nada  
a fazer testes. Lembre-se de que o que está em teste é o seu sistema  
gestor de arquivos temporários, não o sistema de arquivos. ;-)

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

   Você viu acima que existem outras alternativas.
   Aposto que você acha que eu testo a minha interface de base de  
dados com uma base de dados, certo? Ou que eu uso o acesso aos  
serviços SOAP que a minha compania compra nos testes. Não é  
exatamente isso que acontece. Eu tenho um SOAP::Litte::Mock aqui,  
para substituir o SOAP::Litte, e me dar as respostas que eu preciso  
que ele dê (não as que o SOAP vai me dar normalmente). Da mesma  
forma, o meu DBI::Mock produz falhas cabeludas de base de dados que  
eu nunca vi na vida, direitinho, como se elas viessem do banco.

   Exemplo: falha de preparação de SQL é implementada assim:

   package DBI::Mock::SQLPrepareFailure;
   use strict;
   use warnings;
   use base qw/DBI/; # herda funcionalidades do DBI

   sub prepare{
     my $self = shift;
     $DBI::errstr = "Prepare statement failed...";
     $DBI::error = 1;

     if( $self->{PrintError} ){
       print STDERR "Prepare statement failed...";
     }
     if( $self->{RaiseError} ){
       die "Prepare statement failed...";
     }
     return undef;
   }

   __END__

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

   Boa. Esta é uma coisa que eu preciso implementar aqui ainda.
   Mas são 30.000 linhas de código, e eu estou um pouco preocupado  
com isso...
   Talvez eu faça apenas para os módulos principais.

> Nossa, que tratado! Nunca discutam sobre engenharia de software se não
> quiserem me ver tagarelando. ;)

   Certo, certo... eu não vou entrar numa competição.
   Eu acho que vou fazer é começar a montar um novo artigo sobre  
testes. ;-)

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




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