usar unitarias test pruebas integracion framework español ejecutar php phpunit

unitarias - test integracion php



Pasando parámetros a PHPUnit (9)

Estoy empezando a escribir las pruebas de PHPUnit y me gustaría que las pruebas se ejecuten desde las máquinas de los desarrolladores, así como desde nuestros servidores. Las máquinas de los desarrolladores se configuran de manera diferente a los servidores e incluso de manera diferente entre sí.

Para ejecutar en estos diferentes lugares, parece que la persona que realiza la prueba tendrá que indicar dónde se está ejecutando. La prueba puede buscar la configuración adecuada de la máquina en la que se está ejecutando.

Estoy imaginando algo como:

phpunit.bat -X johns_laptop unittest.php

o en el servidor alfa:

phpunit -X alpha unittest.php

En la prueba, podría obtener el valor si el parámetro ''X'' (o lo que sea) y saber, por ejemplo, cuál es la ruta a la raíz de la aplicación para esta máquina.

No parece que la línea de comandos lo permita, ¿o me he perdido algo?


Como Jasir ya mencionó, una solución de una línea sería establecer una variable de entorno antes de la llamada phpunit.

En Linux:

X=alpha phpunit unittest.php

En Windows probablemente:

set X=johns_laptop && phpunit.bat unittest.php

Y dentro de tu script de uso.

getenv(''X'')

leer el valor


Luché con este problema exacto, y se me ocurrió una especie de solución muy práctica pero a la vez práctica: escribo parámetros en un archivo en el disco y los recupero con el método setUp() :

public function setUp() { $this->setBrowser(''firefox''); $this->base_url = file_get_contents("selenium_host"); $this->setBrowserUrl($this->base_url); }

En lugar de llamar directamente a phpunit o paratest , tengo un script de shell para iniciar las pruebas. Este invoca paratest y me permite especificar el número de procesos, así como el host al que me gustaría que se ejecuten las pruebas.

run_all_tests.sh

if [ $1 ] then threads=$1 else threads=5 fi if [ $2 ] then echo $2 > selenium_host else echo ''http://defaulthost.com'' > selenium_host fi vendor/bin/paratest -p$threads -f --colors TestSuite.php

Luego, para ejecutar con 7 hilos contra http://adifferenthost.com :

./run_all_tests.sh 7 ''http://adifferenthost.com''


No creo que las respuestas anteriores resuelvan mi mismo problema.

La respuesta aceptada no es perfecta. De esta manera, las opciones personalizadas siempre deben ponerse al final de la lista de parámetros, y no hay ningún indicador que indique que son opciones personalizadas. Si el número de opciones personalizadas que necesito no es fijo, debo programar mucho para analizar las opciones personalizadas con expresiones regulares o algo así.

La solución de las variables del entorno es buena, pero no natural. Se ve raro.

VAR1=aaa VAR2=bbb VAR3=ccc ./phpunit-custom-option CustomOptionTest.php

La solución shell script más setUp () comparte la misma debilidad con la aceptada. Es posible que deba codificar mucho para analizar el archivo y manejar números impredecibles de opciones personalizadas.

No creo que el script bootstrap sea la solución correcta. Podría usarse para manejar trabajos sucios de forma automática, haciendo las mismas cosas cada vez pero sin tratar con partes de cambio buenas.

No me gustan todas las respuestas anteriores.

Y yo tampoco tengo una buena idea. Pero tal vez lo que he hecho podría darte inspiración. Bifurqué el proyecto phpunit en GitHub, modifiqué un poco el código y lo hice para admitir la función de opción personalizada.

La versión modificada de phpunit, podría aceptar opciones personalizadas como esta:

./phpuint-custom-option --custom var1=value1 --custom var2=value2 CustomOptionTest.php

Y en la prueba, puede visitar las opciones personalizadas accediendo a las variables super globales $ _SERVER

<?php class CustomOptionTest extends PHPUnit_Framework_TestCase { public function testCustomOption() { $this->assertEquals(''value1'', $_SERVER[''var1'']); $this->assertEquals(''value2'', $_SERVER[''var2'']); } }

y puede encontrar mi código here y descargar la versión modificada here (haga clic en el enlace "ver el archivo completo" en la página).

Para tu información Este artículo es la solución similar.


Pasar argumentos en la línea de comando tendría sentido si desea variar los parámetros de prueba por ejecución de prueba. La ejecución de pruebas específicas de host en diferentes máquinas no es la mejor justificación para esta solución.

Para eso, el archivo de configuración PHPUnit puede resultar más adecuado. Le proporciona control sobre las variables específicas del host e incluso de la solicitud, incluida la manipulación de la configuración de php.ini , así como la definición de constantes, variables globales, $_ENV , $_SERVER e incluso $_GET , $_POST , etc. Todo esto se hace bajo el nodo <php> del archivo de configuración, consulte Configuración de las configuraciones INI de PHP, Constantes y Variables globales

Symfony2 utiliza este enfoque y proporciona un phpunit.xml.dist (configuración predeterminada) y un phpunit.xml con tus pruebas de unidad. Este último está diseñado para permitirle personalizarlo para cada máquina sin afectar el repositorio. Luego ejecutarías tus pruebas con:

phpunit -c /path/to/phpunit.xml


Puedes usar el conmutador --bootstrap de PHPUnit para esto.

--bootstrap <file> A "bootstrap" PHP file that is run before the tests.

Luego, haz un archivo bootstrap.php que contenga variables:

$port = 4445;

En tus pruebas, puedes tomar esos valores:

global $port; $this->setPort($port);

Entonces corre:

phpunit --bootstrap boot.php MyTest.php


Si desea ejecutar pruebas en una máquina remota, use ssh y luego ejecútelo. En la máquina local, solo tiene que hacer cd a su directorio raíz y luego ejecutar phpunit.

user@local:/path/to/your/project$ phpunit user@remote:/var/www/project$ phpunit

Edición : se trata de una configuración dependiente de la máquina. (¿Qué tipo de conf por cierto?) Mi solución es poner estas configuraciones en el mismo lugar, no en el de la versión controlada, y luego leerlas / analizarlas en tiempo de ejecución, en los métodos de configuración necesarios, por ejemplo.


Todas las soluciones aquí son válidas para la pregunta, pero hay otra manera que podría ser más simple para algunas situaciones. Phing tomará los argumentos pasados ​​en la forma -Dargument=value

Entonces usando phing -Dtest=MyTest.class.php

Luego puedes usar condicionales de phing para manejar estos argumentos:

<if> <isset property="test" /> <then> <property name="testFile" value="${test}" /> </then> <else> <property name="testFile" value="AllTests.php" /> </else> </if> <exec command="phpunit --bootstrap myTestFile/bootstrap.php- myTestFolder/${testFile}" passthru="true" returnproperty="phpunitreturn" />



Una forma sería que usted inspeccione $ argv y $ argc. Algo como:

<?php require_once ''PHPUnit/Framework/TestCase.php''; class EnvironmentTest extends PHPUnit_Framework_TestCase { public function testHasParam() { global $argv, $argc; $this->assertGreaterThan(2, $argc, ''No environment name passed''); $environment = $argv[2]; } }

Entonces puedes llamar a tu phpunittest así:

phpunit EnvironmentTest.php my-computer