Situation

We're using PHPUnit in our project and are using a phpunit.xml to ensure things like backupGlobals is turned off.

To further ensure the include path is set and autoloading is active, we also cascade our test bootstraps. That is to say, every test and alltests-suite has a require_once(__DIR__ . '/../bootstrap.php'); at the top, all the way up to the base folder level, where it obviously reads require_once(__DIR__ . '/bootstrap.php');, and the actual bootstrap file resides.

Essentially, our tests are autonomous. You can call any AllTests.php in any folder and any *Test.php by itself and they'll run with the right configuration.

Except no. 'Wait a moment.'

That's only true if we either force our developers to use phpunit --configuration=path/to/phpunit.xml or they're in the folder with the phpunit.xml (so that PHPUnit pulls it out of the current working directory when it is executed).

Occasionally, this makes it incredibly hard to determine why tests on one developer's machine are breaking and why they're running on another. It just takes forgetting that the bootstrap is not the only thing we need to have the same test environment. Keep in mind that since you couldn't forget the bootstrap if you tried, because it's in the tests themselves, forgetting other settings, especially usually-optional ones like that (if you're in the folder with the phpunit.xml, it's automatically pulled), is easy.

In fact - it's happened a few times.

Question

Is there a way I can supply which phpunit.xml to use in the test file being run, such as in our conveniently ubiquitous bootstrap file, rather than supplying it to PHPUnit beforehand, be that by command-line switch or by being in its directory ?

A cursory glance at the code suggests the answer is no - configuration well and truly seems to be loaded before test files are even pulled:

[PHPUnit/TextUI/Command.php]
...
if (isset($this->arguments['configuration'])) {
    $configuration = PHPUnit_Util_Configuration::getInstance(
        $this->arguments['configuration']
    );
    $phpunit = $configuration->getPHPUnitConfiguration();
    ...

That does make some sense, given that the configuration can contain test white- or blacklists.

Really, it wouldn't make sense to load test filters in the test bootstrap itself, so that's half the potential configuration out the window with, but the actual behavioural flags of PHPUnit...

[sample of part of our phpunit.xml]
<phpunit
    backupGlobals="false" 
    backupStaticAttributes="false" 
    convertErrorsToExceptions="true"  
    convertNoticesToExceptions="true"
    convertWarningsToExceptions="true"
    syntaxCheck="false"
    processIsolation="false"
    colors="true">

...perhaps with the exception of 'colors' strikes me as something that the test itself should be able to decide on some level.

Consolation prize for...

Admittedly, right now I'd be happy just knowing if I can teach PHPUnit backupGlobals="false" from the bootstrap file, if someone knows of a way.

(If fruitless, the practical answer I'll pursue will probably be to copy the phpunit.xml into all subfolders. I'd like to avoid that solution since it creates redundant copies, and if we ever choose to change a setting... yeah, ouch!)

Direct answer: No, you can't do that.

Longer story - this kind of problem is better solved by changing the habits of developers.

Here is we do it:

• All developers always run the tests from the tests root directory, which has the sole phpunit.xml with all the necessary configuration - including bootstrap, which sets up an class autoloader.
• We don't have testsuites as such, tests are grouped using directories, no AllTests.php anywhere, because its not necessary. PHPUnit can take a name of directory and run all tests inside it.
• Its still possible to run any single test by giving a path to it or whole testsuite (by giving path to the directory). It just has to be done from the tests root directory all the time or it won't work.

Doing it like this means giving up the freedom of starting PHPUnit from any directory, but to be honest - I don't feel like that's a loss at all.

The gains are much bigger: the amount of housekeeping code is reduced, developers cannot forget anything and results are therefore consistent.