[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