Phpunit: Running phpunit.phar generates a lot of Undefined index notices

[roland-d]

Hello,
In an effort to try and get PHPUnit running I see a lot of these notics come by:

Notice: Undefined index: SCRIPT_NAME in phar://D:/server/php/phpunit.phar/phpunit/Util/Filter.php on line 69

Call Stack:
0.0114 367048 1. {main}() D:\server\php\phpunit.phar:0
0.0123 563168 2. PHPUnit_TextUI_Command::main() D:\server\php\phpunit.phar:584
0.0123 566952 3. PHPUnit_TextUI_Command->run() phar://D:/server/php/phpunit.phar/phpunit/TextUI/Command.php:132
1.8032 63293944 4. PHPUnit_TextUI_TestRunner->doRun() phar://D:/server/php/phpunit.phar/phpunit/TextUI/Command.php:179
1.9561 63830200 5. PHPUnit_Framework_TestSuite->run() phar://D:/server/php/phpunit.phar/phpunit/TextUI/TestRunner.php:426
84.4922 135775816 6. PHPUnit_Framework_TestSuite->run() phar://D:/server/php/phpunit.phar/phpunit/Framework/TestSuite.php:675
84.9213 136167344 7. PHPUnit_Framework_TestCase->run() phar://D:/server/php/phpunit.phar/phpunit/Framework/TestSuite.php:675
84.9214 136167312 8. PHPUnit_Framework_TestResult->run() phar://D:/server/php/phpunit.phar/phpunit/Framework/TestCase.php:753
84.9303 136193816 9. PHPUnit_Framework_TestResult->addError() phar://D:/server/php/phpunit.phar/phpunit/Framework/TestResult.php:760
84.9304 136193992 10. PHPUnit_Util_Log_JUnit->addError() phar://D:/server/php/phpunit.phar/phpunit/Framework/TestResult.php:275
84.9304 136194176 11. PHPUnit_Util_Filter::getFilteredStacktrace() phar://D:/server/php/phpunit.phar/phpunit/Util/Log/JUnit.php:176

At the end when it is generating the code coverage report I get these notices:
Notice: Undefined index: REQUEST_TIME in phar://D:/server/php/phpunit.phar/php-code-coverage/CodeCoverage/Report/Clover.php on line 71
Notice: Undefined index: REQUEST_TIME in phar://D:/server/php/phpunit.phar/php-code-coverage/CodeCoverage/Report/Clover.php on line 75

I tried to suppress notices but it seems this is ignored all together making these notices problematic as reading the test results becomes very difficult.

This is running PHPUNit 4.1.0

[sebastianbergmann]

$_SERVER['SCRIPT_NAME'] and $_SERVER['REQUEST_TIME'] are always available. If they are not then only because they are explicitly unset() somewhere.

[roland-d]

I checked the Joomla core code and these are not unset anywhere. Could it have something to do that I am running it from the Windows command line? Using PHP 5.5.10 on Windows 8.1.

From: Sebastian Bergmann [mailto:[email protected]]
Sent: donderdag 8 mei 2014 07:40
To: sebastianbergmann/phpunit
Cc: RolandD
Subject: Re: [phpunit] Running phpunit.phar generates a lot of Undefined index notices (#1255)

$_SERVER['SCRIPT_NAME'] and $_SERVER['REQUEST_TIME'] are always available. If they are not then only because they are explicitly unset() somewhere.

—
Reply to this email directly or view it on GitHub https://github.com/sebastianbergmann/phpunit/issues/1255#issuecomment-42515035 . https://github.com/notifications/beacon/359377__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNTE0Njc4NywiZGF0YSI6eyJpZCI6MzE3MTc2OTF9fQ==--af91bec60135b92768bef1eb914a9277cd55a41e.gif

[whatthejeff]

I'm going to close this as it's almost certainly not a PHPUnit issue. These values should always be set in the standard cli sapi. If something in PHPUnit were unsetting these values, we would have more than one person reporting this issue.

Here's what I would suggest–make a new folder and put your PHPUnit phar in it. Add one new test file to the folder called MyTest.php that contains the following:

<?php

class MyTest extends PHPUnit_Framework_TestCase {
    public function testServer() {
        $this->assertArrayHasKey('SCRIPT_NAME', $_SERVER);
        $this->assertArrayHasKey('REQUEST_TIME', $_SERVER);
    }
}

Then run this test with:

php phpunit.phar --no-configuration MyTest.php

If the test passes, then something is wrong with your other test suite. If the test fails, then something is wrong with your environment.

[nibra]

I came across the same issue recently from one moment to the other after an composer update. As far as I can tell, there happened some mess with the autoloader. My work-around is to run the tests in a docker container.

[davidjeddy]

Same issue as @nibra but do not have the option to run in a container. App stack: CentOS6, Apache2.3, MySQL 5.6, PHP 5.6, Yii 2.0.6, CodeCeption 2.2.

./vendor/bin/codecept run --coverage --coverage-xml --coverage-html
...
Time: 5.93 seconds, Memory: 46.50MB

OK (8 tests, 17 assertions)


  [PHPUnit_Framework_Exception]  
  Undefined index: REQUEST_TIME  


run [--report] [--html [HTML]] [--xml [XML]] [--tap [TAP]] [--json [JSON]] [--colors] [--no-colors] [--silent] [--steps] [-d|--debug] [--coverage [COVERAGE]] [--coverage-html [COVERAGE-HTML]] [--coverage-xml [COVERAGE-XML]] [--coverage-text [COVERAGE-TEXT]] [--no-exit] [-g|--group GROUP] [-s|--skip SKIP] [-x|--skip-group SKIP-GROUP] [--env ENV] [-f|--fail-fast] [--no-rebuild] [--] [<suite>] [<test>]

[fps01]

@davidjeddy I've same problem. Tell me please if you fix it.
Can someone help us with it?

PHP5.5.9 Ubuntu 14.04 PHPUnit 4.8.26 Codeception 2.2.3 Yii 2

Command:
vendor/codeception/codeception/codecept run functional --coverage-html /home/user/www/report --verbose

Part of output:

Time: 689 ms, Memory: 33.75MB

OK (1 test, 2 assertions)


  [yii\base\ErrorException (8)]  
  Undefined index: REQUEST_TIME  


Exception trace:
 () at /home/user/www/myproject/vendor/phpunit/php-code-coverage/src/CodeCoverage/Report/Text.php:121
 Codeception\Coverage\Subscriber\Printer->printConsole() at /home/user/www/myproject/vendor/codeception/codeception/src/Codeception/Coverage/Subscriber/Printer.php:62
 Codeception\Coverage\Subscriber\Printer->printResult() at /home/user/www/myproject/vendor/symfony/event-dispatcher/EventDispatcher.php:174
 ::call_user_func() at /home/user/www/myproject/vendor/symfony/event-dispatcher/EventDispatcher.php:174
 Symfony\Component\EventDispatcher\EventDispatcher->doDispatch() at /home/user/www/myproject/vendor/symfony/event-dispatcher/EventDispatcher.php:43
 Symfony\Component\EventDispatcher\EventDispatcher->dispatch() at /home/user/www/myproject/vendor/codeception/codeception/src/Codeception/Codecept.php:226
 Codeception\Codecept->printResult() at /home/user/www/myproject/vendor/codeception/codeception/src/Codeception/Command/Run.php:271
 Codeception\Command\Run->execute() at /home/user/www/myproject/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /home/user/www/myproject/vendor/symfony/console/Application.php:821
 Symfony\Component\Console\Application->doRunCommand() at /home/user/www/myproject/vendor/symfony/console/Application.php:187
 Symfony\Component\Console\Application->doRun() at /home/user/www/myproject/vendor/symfony/console/Application.php:118
 Symfony\Component\Console\Application->run() at /home/user/www/myproject/vendor/codeception/codeception/src/Codeception/Application.php:103
 Codeception\Application->run() at /home/user/www/myproject/vendor/codeception/codeception/codecept:33

run [--report] [--html [HTML]] [--xml [XML]] [--tap [TAP]] [--json [JSON]] [--colors] [--no-colors] [--silent] [--steps] [-d|--debug] [--coverage [COVERAGE]] [--coverage-html [COVERAGE-HTML]] [--coverage-xml [COVERAGE-XML]] [--coverage-text [COVERAGE-TEXT]] [--no-exit] [-g|--group GROUP] [-s|--skip SKIP] [-x|--skip-group SKIP-GROUP] [--env ENV] [-f|--fail-fast] [--no-rebuild] [--] [<suite>] [<test>]

[davidjeddy]

@fps01 No fix yet, sadly means setup on code coverage has halted :S.

[tyteen4a03]

I'm not sure if this is related to this issue, but I have some tests here and they seem to be failing with the same error message. I checked my code and the code involved does not modify globals.

[flowl]

I have the same problem using PHP 5.5, composer, PHPUnit 3 & 4, ZF1.

Notice: Undefined index: SCRIPT_NAME in vendor/phpunit/phpunit/src/Util/Filter.php on line 29

I even put the following in my bootstrap.php

$_SERVER['SCRIPT_NAME'] = __FILE__;
$GLOBALS['_SERVER']['SCRIPT_NAME'] = __FILE__;

Without success. I the only logical reason is something (composer, xdebug, ... ) is unsetting either of those superglobals. Or could it be caused by some process isolation stuff?

[flowl]

I added the 'do not convert warnings to exceptions' to the phpunit xml:

<phpunit
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.8/phpunit.xsd"
        colors="true" bootstrap="bootstrap.php"
        convertNoticesToExceptions="false"
        convertWarningsToExceptions="false">

and REMOVED all @runInSeperateProcess annotations (there was only 1 in our whole code).
The Superglobals still get lost somewhere in PHPUnit!
(Ending in vendor/phpunit/phpunit/src/Util/Filter.php, getFilteredStacktrace().)

I reverted the changes because they didn't really help.

---

$_SERVER['SCRIPT_NAME'] and $_SERVER['REQUEST_TIME'] are always available. If they are not then only because they are explicitly unset() somewhere.

• @sebastianbergmann

I don't think this is true (at least in current setup), it is PHPUnit that loses the superglobals at some point. Maybe during some error handling stage (in a custom error handler) or in an isolated process, the superglobals are not available and lead to strange behaviour of the tests.

The following solved most of the problems for me, because we do test warnings in some cases:

This does not work to test warnings:

$this->setExpectedException('Exception'); // or '\Exception'

This does work:

$this->setExpectedException('PHPUnit_Framework_Error_Warning');

Although PHPUnit_Framework_Error_Warning does extend \Exception !

[andreskrey]

Just FYI, in my case I have one test with the following assignment:

$_SERVER = [
    'Test-Header' => 'dummyData'
];

This was overwriting the $_SERVER var completely, deleting critical keys like REQUEST_TIME. I solved this by assigning keys directly instead of declaring a new array:

$_SERVER['Test-Header'] = 'dummyData';

[BafS]

Any new about this issue ? SCRIPT_NAME is not always set. Some frameworks like Slim 2 seems to unset the variable.

[andreskrey]

@BafS Then it's not PHPUnit's problem

[BafS]

@andreskrey sure but it could help a lot to handle this case in PHPUnit, it's a risk to assume that this variable will always be set imho.