2010-05-14 9 views

Respuesta

9

escribir un módulo como rjh ha demostrado. Puso en t/lib/Prueba/YourThing.pm, entonces se puede cargar como:

use lib 't/lib'; 
use Test::YourThing; 

O se puede poner directamente en t/Prueba/YourThing.pm, lo llaman package t::Test::YourThing y cargarlo como:

use t::Test::YourThing; 

la ventaja es no tener que escribir la línea use lib en cada archivo de prueba, e identificar claramente como un módulo de prueba local. El lado negativo está abarrotado t /, no funcionará si "." no está en @INC (por ejemplo, si ejecuta las pruebas en modo de atenuación, pero se puede solucionar con use lib ".") y si decide mover el archivo .pm fuera de su proyecto, debe volver a escribir todos los usos. Tu elección.

+0

Está bien, por el momento voy a ir con este, incluso si voy a echar un vistazo a Test :: Builder en un momento. – zedoo

11

El mejor enfoque es poner sus funciones de prueba, como cualquier otro conjunto de funciones, en un módulo. Luego puede usar Test::Builder para que los mensajes de diagnóstico de prueba/falla actúen como si la falla se originara en el archivo .t, en lugar de su módulo.

Aquí hay un ejemplo simple.

package Test::YourModule; 

use Test::Builder; 
use Sub::Exporter -setup => { exports => ['exitcode_ok'] }; # or 'use Exporter' etc. 

my $Test = Test::Builder->new; 

# Runs the command and makes sure its exit code is $expected_code. Contrived! 
sub exitcode_ok { 
    my ($command, $expected_code, $name) = @_; 

    system($command); 
    my $exit = $? >> 8; 
    my $message = $!; 

    my $ok = $Test->is_num($exit, $expected_code, $name); 
    if (!$ok) { 
     $Test->diag("$command exited incorrectly with the error '$message'"); 
    } 

    return $ok; 
} 

En la secuencia de comandos:

use Test::More plan => 1; 
use Test::YourModule qw(exitcode_ok); 
exitcode_ok('date', 0, 'date exits without errors'); 
+1

Estoy de acuerdo con todo esto, pero generalmente pondría la funcionalidad específica de la prueba en un módulo en el directorio t /, por lo que no se puede confundir con la aplicación real, p. en MyApp/t/Common.pm, con el nombre del paquete MyApp :: t :: Common. – Ether

+4

Recomendaría Test :: Builder :: Module, ya que se encargará de escribir una importación inteligente() para usted, una que pueda manejar un plan de prueba. Esto permite que su módulo sea independiente de Test :: More. – Schwern

+1

Esto es un poco pesado cuando el código común que desea compartir no está probando nada. Las funciones de utilidad y varias otras cosas que no van a emitir TAP no se beneficiarán de un contenedor Test :: Builder. –

Cuestiones relacionadas