Existem convenções para nomes de funções ao usar Perl Test::More?

Question

Existem convenções para nomes de funções ao usar os módulos Perl Test::More ou Test::Simple?

Estou perguntando especificamente sobre os nomes das funções usadas para configurar um ambiente de teste antes do teste e para desmontar o ambiente após a conclusão bem-sucedida do(s) teste(s).

saúde,

Roubar

Answer 1

Não creio que existam tais convenções por aí.

A única maneira de fazer isso é talvez usar blocos BEGIN/END, se os recursos forem usados ​​em todo o arquivo.

A abordagem geral que adoto é colocar testes relacionados em um bloco de código e, em seguida, inicializar as variáveis/recursos etc.Talvez você possa manter uma contagem fácil de quantos testes possui para cada função.

Algo como ...

BEGIN {
   # If you want to set some global db setting/file setting/INC changes etc
}

# Tests functionality 1...
{
     # have fun .... 
}

# Tests functionality 2...
{
     # have more fun .... 
}

END {
   # Clean up the BEGIN changes
}

Por outro lado, você pode querer ler isto para testar em perl ... http://perlandmac.blogspot.com/2007/08/using-perl-testsimple-and-testmore.html

Answer 2

Se você estiver procurando por mais testes no estilo XUnit, confira Teste::Aula.Ele fornece o Test(setup) e Test(teardown) atributos para métodos que, bem, configuram e desmontam seu ambiente.Ele também oferece uma maneira muito mais agradável de lidar com planos (você pode fornecer um para cada método de teste individualmente, para que a contagem seja muito menos complicada) e permite herdar testes por meio de hierarquias de classes de teste.

Answer 3

Não creio que exista um conjunto oficial de convenções, por isso recomendo olhar os exemplos em http://perldoc.perl.org/Test/More.html e veja como eles escrevem seus testes.

Answer 4

Usamos Test::Mais extensivamente para nossos testes de unidade, já que muitos (a maioria) de nossos scripts de processamento de dados são escritos em Perl.Não temos uma convenção específica para os nomes das funções, mas fazemos algo como Jagmal sugere, ou seja, dividir os testes em pedaços menores e inicializar localmente.

No nosso caso, cada subteste é encapsulado em uma função separada dentro do script de teste.Além disso, temos uma estrutura que nos permite executar todos os subtestes (o teste unitário completo) ou chamar subtestes individuais ou conjuntos de subtestes para permitir a execução apenas daqueles em que estamos trabalhando no momento.

Answer 5

Obrigado Espo.

Dei uma olhada nos perldocs relevantes, mas não há nenhuma convenção real em relação aos aspectos de configuração e desmontagem.

Diferente da série de testes XUnit.

Obrigado pela resposta Jagmal, mas não tenho certeza sobre o uso dos blocos BEGIN e END para configuração e desmontagem, pois você não está deixando claro o que está fazendo pelos nomes.Há também o problema óbvio de ter apenas uma execução de configuração e uma execução de desmontagem por teste, ou seja,por cada arquivo .t.

Dei uma olhada rápida em Test::Most e parece muito interessante, especialmente a função de explicação.Obrigado Matt.

Hmmm.Pensando ainda mais em usar os blocos BEGIN e END, estou pensando que se eu diminuir a granularidade dos testes para que haja apenas uma configuração e uma desmontagem necessária, então esta seria uma boa solução.

saúde,

Roubar

Answer 6

A primeira convenção que sugiro é abandonar Test::More para Test::Most

Answer 7

Os scripts de teste Perl não são especiais ou mágicos de forma alguma.Como tal, eles podem conter exatamente as mesmas coisas que qualquer outro script Perl pode.

Você pode nomear as rotinas como quiser e chamá-las antes, depois e entrelaçadas com seus testes.

Você pode ter qualquer quantidade de código de inicialização antes de qualquer teste, qualquer quantidade de código de limpeza após os testes e qualquer quantidade de qualquer outro código misturado aos testes.

Tudo isso pressupõe que você esteja falando sobre scripts de teste t/*.t no estilo CPAN.Acho que sim, mas consigo interpretar sua pergunta como uma pergunta sobre a extensão dos equipamentos de teste, se eu apertar os olhos corretamente.

Answer 8

Se você também está aberto para fazer testes de aceitação, como Ruby's Cucumber - dê uma olhada neste pequeno exemplo http://github.com/kesor/p5-cucumber isso está usando Test::More e um estilo pepino de teste de aceitação.