2010-10-20 7 views
9

Situación

Estamos utilizando PHPUnit en nuestro proyecto y estamos utilizando un phpunit.xml para asegurar cosas como backupGlobals está apagado.Configuración PHPUnit (phpunit.xml) - cargando en un arranque?

Para garantizar que la ruta de inclusión esté configurada y la carga automática esté activa, también conectamos en cascada nuestras pruebas de arranque. Es decir, cada prueba y alltests-suite tiene un require_once(__DIR__ . '/../bootstrap.php'); en la parte superior, hasta el nivel de la carpeta base, donde obviamente lee require_once(__DIR__ . '/bootstrap.php');, y reside el archivo de arranque real.

Esencialmente, nuestras pruebas son autónomas. Puede llamar a cualquier AllTests.php en cualquier carpeta y cualquier *Test.php por sí mismo y se ejecutarán con la configuración correcta.

Excepto no. 'Espera un momento. '

eso sólo es cierto si bien forzar a nuestros desarrolladores a utilizar phpunit --configuration=path/to/phpunit.xml o que están en la carpeta con el phpunit.xml (de modo que PHPUnit lo saca del directorio de trabajo actual cuando se ejecuta).

Ocasionalmente, esto hace que sea increíblemente difícil determinar por qué las pruebas en la máquina de un desarrollador se están rompiendo y por qué se están ejecutando en otra. Simplemente se necesita olvidar que el bootstrap es no lo único que necesitamos para tener el mismo ambiente de prueba. Tenga en cuenta que, dado que no podía olvidar el arranque, si lo intentó, porque está en las pruebas, olvidando otras configuraciones, especialmente las opciones opcionales (si está en la carpeta con el phpunit.xml, se activa automáticamente) , es fácil.

De hecho, ha sucedido algunas veces.

Pregunta

¿Hay alguna manera de suministrar el cual phpunit.xml a utilizar en el archivo de prueba que se está ejecutando, como en nuestro archivo de arranque convenientemente ubicua, en lugar de suministrarla a PHPUnit antemano, sea por el cambio de línea de comandos o por estar en su directorio ?

Un rápido vistazo al código sugiere la respuesta es no - configuración bien y verdaderamente parece estar cargado antes de archivos de prueba son incluso sacaron:

[PHPUnit/TextUI/Command.php] 
... 
if (isset($this->arguments['configuration'])) { 
    $configuration = PHPUnit_Util_Configuration::getInstance(
     $this->arguments['configuration'] 
    ); 
    $phpunit = $configuration->getPHPUnitConfiguration(); 
    ... 

Eso tiene algún sentido, dado que la configuración puede contiene listas blancas o negras de prueba.

En realidad, no tendría sentido de carga de prueba filtros en la prueba de arranque en sí, por lo que es la mitad de la configuración potencial por la ventana con, pero las banderas reales de comportamiento de PHPUnit ...

[sample of part of our phpunit.xml] 
<phpunit 
    backupGlobals="false" 
    backupStaticAttributes="false" 
    convertErrorsToExceptions="true" 
    convertNoticesToExceptions="true" 
    convertWarningsToExceptions="true" 
    syntaxCheck="false" 
    processIsolation="false" 
    colors="true"> 

... tal vez con la excepción de 'colores' me parece algo que la prueba en sí misma debería poder decidir en algún nivel.

Consolation prize for ...

Es cierto, en este momento me alegra saber si puedo enseñar PHPUnit backupGlobals="false" desde el archivo de arranque, si alguien sabe de alguna manera.

(Si infructuosa, la respuesta práctica Voy a persigo probablemente será copiar el phpunit.xml en todas las subcarpetas. Me gustaría evitar que la solución ya que crea copias redundantes, y si alguna vez decido cambiar un ajuste ... sí, ¡ay!)

Respuesta

10

Respuesta directa: No, no puedes hacer eso.

Una historia más larga: este tipo de problema se resuelve mejor cambiando los hábitos de los desarrolladores.

Aquí está lo hacemos:

  • Todos los desarrolladores siempre se ejecutan las pruebas del directorio de pruebas de raíz, que tiene el único phpunit.xml con toda la configuración necesaria - incluyendo arranque, que establece un cargador automático de clases .
  • No tenemos testsuites como tales, las pruebas se agrupan utilizando directorios, no AllTests.php en ninguna parte, porque no es necesario. PHPUnit puede tomar el nombre del directorio y ejecutar todas las pruebas dentro de él.
  • Todavía es posible ejecutar una única prueba al proporcionarle una ruta o un conjunto de pruebas completo (dando la ruta al directorio). Solo tiene que hacerse desde el directorio raíz de las pruebas todo el tiempo o no funcionará.

Hacerlo así significa renunciar a la libertad de iniciar PHPUnit desde cualquier directorio, pero para ser sincero, no siento que sea una pérdida en absoluto.

Las ganancias son mucho mayores: la cantidad de código de limpieza se reduce, los desarrolladores no pueden olvidar nada y los resultados son consecuentes.

+0

Mira, nuestro problema es que tenemos esa primera política, pero los desarrolladores se lo dicen una vez y no hay nada que les recuerde hacerlo.Funciona en 99 casos de un centenar, cuando desea ejecutar el conjunto de pruebas completo de todos modos, porque debe asegurarse de que los cambios no sean destructivos, y lo hace desde el directorio raíz, y luego se olvida cuando quiero hacer una nueva prueba rápida de una rama de directorio. – pinkgothic

+0

En eso, creo que su punto # 2 es muy perspicaz; quizás eliminar AllTests.php en los subdirectorios "forzaría" un poco mejor el proceso de pensamiento, serviría como un recordatorio del 'phpunit.xml'. Voy a pensar un poco más y rebotar en mis colegas, tal vez esa es la mejor solución. – pinkgothic

+0

Es una elección entre cambiar los hábitos y crear un infierno de mantenimiento (con muchos archivos de configuración que deben sincronizarse). Buena suerte :) –

4

Mi solución es añadir una función fiesta

function phpu() 
{ 
    phpunit --colors --bootstrap ~/path/to/bootstrap.php "[email protected]"; 
} 

A continuación, añadir esto a todos los archivos Dev .bashrc y pueden pasar a usar eso.

Nos gusta llamarlos desde vim por lo que tuvieron que añadir esto a .vimrc:. set shellcmdflag=-ic

a continuación, agregar nmap ;t :! phpu % para ejecutar el archivo de prueba que está actualmente en

0

Se podría actualizar el script de inicio (Windows bat archivo, o shell en * nix) y tienen lógica allí para configurar la ubicación de phpunit.xml. Si está en el directorio actual, úselo, de lo contrario apunte al principal.

También estoy de acuerdo con Anti, que todas las pruebas siempre deben ejecutarse, ya que quiere asegurarse de que los cambios, incluso en una rama del directorio, no afecten a otros códigos. Por lo tanto, siempre corra desde la parte superior del árbol. Esto también requiere que la prueba se ejecute rápidamente, pero realmente no he tenido ningún problema con PHPUnit en eso.

El mantenimiento de PHPUnit.xml en cada directorio sería una pesadilla de mantenimiento, a menos que se vincule simbólicamente desde otras rutas para garantizar que haya solo un archivo real.

Cuestiones relacionadas