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 elegante de pasar variables a los archivos de arranque tanto como a los archivos de prueba es mediante el uso de variables de entorno:
export MY_ENV_VAR="some value"
phpunit all
Luego, en tus archivos PHP, puedes acceder a él de esta manera:
getenv(''MY_ENV_VAR'')
Fuente: http://blog.lysender.com/2010/10/phpunit-passing-environment-variable-to-your-application/
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