Вызов PHPUnit из команды Artisan будет игнорировать файл XML

У меня есть то, что я считаю необычной проблемой, но я постараюсь объяснить как можно яснее. Я создал простую ремесленную команду, которая делает это

 /**
 * Execute the console command.
 */
public function handle()
{
    $this->info("==> Cleaning up reports and docs...");

    $command = new Process("rm -f tests/docs/* && rm -rf test/reports/*");
    $command->run();

    $this->warn("==> Reports and docs are clean");

    $this->info("==> Executing Tests Suite...");
    $command = new Process("vendor/bin/phpunit --coverage-html tests/reports --testdox-html tests/docs/reports.html -v --debug");
    $command->run();
    $this->info($command->getIncrementalOutput());

    $this->warn("==> report generated >> test/reports. Documentation generated >> test/docs/reports.html");
}

Это может показаться странным, но на самом деле это довольно полезно, он запускает PHPUnit с поддержкой покрытия и другими вещами. Проблема в том, что если я запущу эту команду, например php artisan ludo237:full-test, она полностью проигнорирует phpunit.xml, на самом деле она будет отображать ошибку, говорящую о том, что база данных MySQL не существует, хотя я установил соединение sqlite внутри моего phpunit.xml, говоря о котором вы можете ясно видеть, что это правильно:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit backupGlobals="false"
         backupStaticAttributes="false"
         bootstrap="bootstrap/autoload.php"
         colors="true"
         convertErrorsToExceptions="true"
         convertNoticesToExceptions="true"
         convertWarningsToExceptions="true"
         processIsolation="false"
         stopOnFailure="false">
    <testsuites>
        <testsuite name="Application Test Suite">
            <directory suffix="Test.php">./tests</directory>
        </testsuite>
    </testsuites>
    <filter>
        <whitelist processUncoveredFilesFromWhitelist="true">
            <directory suffix=".php">./app</directory>
        </whitelist>
    </filter>
    <php>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_DEBUG" value="true"/>
        <env name="APP_URL" value="http://localhost:8000"/>
        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:" />
        <env name="CACHE_DRIVER" value="array"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="QUEUE_DRIVER" value="sync"/>
        <env name="MAIL_DRIVER" value="log"/>
        <env name="MAIL_PRETEND" value="true"/>
    </php>
</phpunit>

Я знаю, что могу просто создать псевдоним bash для этой командной строки, на самом деле это мое текущее исправление, но на данный момент мне просто любопытно понять, почему, когда я запускаю команду phpunit из команды artisan, она игнорирует XML файл.

Кто-нибудь знает об этом? Благодарю вас!


person Claudio Ludovico Panetta    schedule 11.11.2016    source источник


Ответы (1)


Мне потребовалось очень много времени, чтобы отладить это, но в конце концов я нашел, почему это не работает.

Прежде всего, позвольте мне уточнить, что с вашим кодом все в порядке, даже если с классом Process все в порядке, вы получите такое же поведение, даже используя нативную функцию exec.

Во-вторых, файл phpunit.xml полностью читается, никаких проблем.

Сказал, что реальная проблема заключается в PHPUnit, который не позволяет вам переопределять (или переопределять) любую переменную env, потому что есть проверка, предотвращающая это.

Это связано с тем, что Laravel не анализирует сам файл phpunit.xml, и в тот момент, когда вы его вызываете, уже слишком поздно и переменные среды определяются через putenv, $_SERVER и/или $_ENV.

Из-за этого я создал Issue на PHPUnit, который даже в последних версиях (как на сегодняшний день), эта проблема сохраняется, даже если этот уже был задан в прошлом.

К сожалению, у меня пока нет для вас решения, но давайте скрестим пальцы и подождем, пока PHPUnit добавит предложенный атрибут force :)

С уважением, Джулиан

person Julian Xhokaxhiu    schedule 11.11.2016
comment
Спасибо за ваши усилия, давайте посмотрим, будет ли у проблемы какое-либо обновление. - person Claudio Ludovico Panetta; 11.11.2016