2009-11-11 15 views
13

Noté que en Perl la costumbre es pegar todas las pruebas en el directorio t. ¿Cómo separe la prueba unitaria de las funcionales? O, para hacer la pregunta más simple y más obvia, ¿cómo separe las pruebas que se ejecutan rápidamente de las que no? Cuando todas las pruebas se ejecutan juntas, las pruebas tardan demasiado en ser utilizadas rutinariamente en el desarrollo, lo cual es una lástima.¿Cómo puedo separar diferentes tipos de pruebas de Perl para que no tenga que ejecutarlas todas?

Pensé que podría establecer alguna variable de entorno como QUICK_TEST y omitir las pruebas largas según su valor. ¿Separe las pruebas de unidad y funcionales? ¿Cómo? (Esto no pretende ser una encuesta - Sólo pensé que tal vez hay alguna solución idiomática.)


Actualización: Hasta aquí he llegado a esto:

package Test::Slow; 

use strict; 
use Test::More; 

BEGIN { 
    plan(skip_all => 'Slow test.') if $ENV{QUICK_TEST}; 
} 

1; 

Y en una cercana .t file:

# This is a slow test not meant 
# to run frequently. 
use Test::Slow; 
use Test::More; 

Parece que funciona bien.

P.S. Ahora disponible como Test::Slow en CPAN.

Respuesta

7

Sin duda puede dividir las pruebas en subdirectorios en t, con el esquema de categorización que desee. Si usa una variable de entorno, le recomendaría hacer que el valor predeterminado (si la variable no está establecida) sea ejecutar todas las pruebas. He visto situaciones en las que t/contiene solo las pruebas que se ejecutarán de forma rutinaria en el desarrollo y otras pruebas se colocan en un directorio diferente (por ejemplo, t-selenio /).

Creo que se reduce a la coherencia, siendo más importante que la elección que elija; casi todo funcionará si eres consecuente.

3

Por lo general, la prueba de solo autor se coloca en el directorio xt. Se ejecutan manualmente. Por lo tanto, si las pruebas largas son solo de autor, use xt. En general, t es común para los módulos de CPAN. Para uso privado, puede ponerlos en cualquier lugar que desee.

+0

No sé si es "por lo general"; He visto el uso de variables de entorno, directorios separados, omisión de pruebas si los módulos (por ejemplo, Test :: Pod :: Cobertura) no están instalados, incluso las comprobaciones de nombre de usuario o directorio codificadas. Veo todo esto, en mayor o menor grado, como impedimentos para cualquier persona que no sea el autor que trabaja en un módulo y deseo que la gente simplemente no se moleste. Las pruebas de solo autor rara vez son tan costosas de ejecutar. – ysth

10

Ejecute prove --state=all,save una vez para obtener información agregada a .prove.

Ejecute prove --state=slow -j9 si tiene una máquina multi-core y sus pruebas se pueden ejecutar al mismo tiempo. Esto hará que comiencen sus pruebas de funcionamiento más prolongado al principio, de modo que es más probable que finalicen antes de que se realicen todas sus otras pruebas. Esto podría reducir el tiempo total hasta la finalización, sin impedir que se ejecuten pruebas.

+0

Algunas de las pruebas son demasiado lentas para ser utilizadas de manera rutinaria incluso en una máquina multinúcleo, pero las sugerencias 'prueban' son interesantes, gracias. – zoul

2

En Test::Manifest, tengo una manera de asignar un nivel a cada archivo de prueba. El archivo de prueba solo se ejecuta si el nivel de prueba está por encima de ese umbral. El nivel bajo sería lo que quiero ejecutar todo el tiempo, el siguiente nivel, las cosas ligeramente más lentas, y así sucesivamente.

Sin embargo, casi nunca lo uso. Si yo estoy concentrado en una parte de un sistema, acabo de ejecutar la prueba para esa parte:

% perl -Mblib t/some_test.t 

Algunas personas les gusta usar prove a hacer lo mismo.

Solo termino ejecutando el conjunto de pruebas completo cuando necesito las pruebas de integración para ver si mis cambios rompieron cualquier otra cosa.

Cuestiones relacionadas