Передача параметров в PHPUnit

Я начинаю писать тесты PHPUnit, и мне бы хотелось, чтобы тесты запускались с машин разработчиков, а также с наших серверов. Машины разработчиков настроены иначе, чем серверы и даже по-разному друг от друга.

Для запуска в этих разных местах, кажется, человек, который запускает тест, должен будет указать, где он выполняется. Затем тест может найти правильную конфигурацию машины, на которой он работает.

Я представляю себе что-то вроде:

phpunit.bat -X johns_laptop unittest.php

или на альфа-сервере:

phpunit -X alpha unittest.php

В тесте я мог бы получить значение, если параметр «X» (или что-то еще) это, например, то, что путь к корню приложения для этой машины.

Это не похоже на то, что для командной строки это позволяет – или я что-то пропустил?

Один из способов был бы для вас проверить $ argv и $ argc. Что-то вроде:

<?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]; } } 

Затем вы можете вызвать свой phpunittest следующим образом:

 phpunit EnvironmentTest.php my-computer 

Для этого вы можете использовать переключатель –bootstrap для PHPUnit.

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

Затем создайте файл bootstrap.php, содержащий переменные:

 $port = 4445; 

В ваших тестах вы можете получить эти значения:

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

Затем выполните:

 phpunit --bootstrap boot.php MyTest.php 

Элегантный способ передачи переменных как для файлов начальной загрузки, так и для тестирования файлов – это использование переменных среды:

 export MY_ENV_VAR="some value" phpunit all 

Затем в ваших файлах PHP вы можете получить доступ к нему следующим образом:

 getenv('MY_ENV_VAR') 

Источник: http://blog.lysender.com/2010/10/phpunit-passing-environment-variable-to-your-application/

Я не думаю, что ответы выше решают мою проблему.

Принятый ответ не идеален. Таким образом, пользовательские параметры всегда должны быть помещены в конец списка параметров, и нет индикатора, указывающего, что они являются настраиваемыми параметрами. Если количество настраиваемых параметров, которые мне нужны, не исправлено, я должен много кода, чтобы анализировать пользовательские параметры с помощью регулярных выражений или что-то в этом роде.

Решение переменных окружения является хорошим, но не естественным. Выглядит странно.

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

Сценарий оболочки и решение setUp () разделяют ту же слабость с принятой. Может быть, вам нужно много кода, чтобы разобрать файл и обрабатывать непредсказуемые количества настраиваемых опций.

Я не думаю, что сценарий начальной загрузки является правильным решением. Он может использоваться для работы с грязными работами автоматически, делая то же самое каждый раз, но не имея дело с деталями изменений.

Мне не нравятся все вышеперечисленные ответы.

И я тоже не очень хорошо себя понимаю. Но, возможно, то, что я сделал, может дать вам вдохновение. Я разветвил проект phpunit на GitHub и немного изменил код и сделал его для поддержки настраиваемой опции.

введите описание изображения здесь

Модифицированная версия phpunit может принимать пользовательские параметры:

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

И в тесте вы можете посетить пользовательские параметры, обратившись к супер глобальным переменным $ _SERVER

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

и здесь вы можете найти мой код и загрузить измененную версию здесь (щелкнув ссылку «просмотреть полный файл» на странице).

FYI. эта статья является аналогичным решением.

Все решения здесь справедливы для вопроса, но есть еще один способ, который может быть проще для некоторых ситуаций. Phing примет аргументы, переданные в форме -Dargument=value

Итак, используя phing -Dtest=MyTest.class.php

Затем вы можете использовать термины phing для обработки этих аргументов:

 <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" /> 

Я боролся с этой точной проблемой и придумал своеобразное хакерское, но удобное решение: я пишу параметры в файл на диске и извлекаю их в setUp() :

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

Вместо phpunit вызова phpunit или paratest меня есть сценарий оболочки для запуска тестов. Этот paratest вызывает paratest и позволяет указать количество процессов, а также хост, с которым мне бы хотелось пройти тесты.

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 

Затем, чтобы запустить 7 потоков против http://adifferenthost.com :

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

Передача аргументов в командной строке имеет смысл, если вы хотите изменить параметры теста на тестовый прогон. Выполнение конкретных тестов на разных машинах не является лучшим оправданием для этого решения.

Для этого файл конфигурации PHPUnit может оказаться более подходящим. Он дает вам контроль над параметрами, зависящими от хоста и даже запроса, включая управление настройками php.ini , а также определение констант, глобальных переменных, $_ENV , $_SERVER и даже $_GET , $_POST и т. Д. Это все делается под <php> файла конфигурации, см. Настройка параметров PHP INI, константы и глобальные переменные

Symfony2 использует этот подход и предоставляет как phpunit.xml.dist (конфигурацию по умолчанию), так и phpunit.xml с вашими модульными тестами. Последний является gitignored, чтобы вы могли настроить его для каждой машины, не влияя на репо. Затем вы проведете свои тесты с помощью:

 phpunit -c /path/to/phpunit.xml 

Если вы хотите запустить тесты на удаленном компьютере, используйте ssh, затем запустите его. На локальном компьютере вам нужно только подключиться к корневому каталогу, а затем запустить phpunit.

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

Изменить : вы говорите о конфигурации, зависящей от машины. (Что такое conf btw?) Мое решение состоит в том, чтобы поместить эти конфиги в то же самое, а не в контролируемое версией место, а затем прочитать / проанализировать его во время выполнения, в случае необходимости настроить методы, например.

Как уже упоминал Джасир, однострочным решением было бы установить переменную среды перед вызовом phpunit.

В Linux:

 X=alpha phpunit unittest.php 

В Windows возможно:

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

И внутри вашего скрипта используйте

 getenv('X') 

читать значение