I don't think answers above solve my same problem.
The accepted answer is not perfect. In this way, custom options should always be put to the end of the parameters list, and there is no indicator to tell that they are custom options. If the number of custom options which I need is not fixed, I should code a lot to parse custom options with regular expressions or something like that.
The environment variables solution is good, but not natural. Looks weird.
VAR1=aaa VAR2=bbb VAR3=ccc ./phpunit-custom-option CustomOptionTest.php
The shell script plus setUp() solution share the same weakness with the accepted one. May be you should code a lot to parse the file and handle unpredictable numbers of custom options.
I don't think the bootstrap script is the correct solution. It could be used to handle dirty works automatically, with doing same things every time but not dealing with change parts good.
I don't like all the above answers.
And I have no good idea myself too. But maybe what I've done could give you inspiration. I've forked the phpunit project on GitHub, and modified code a little, and made it to support the custom option feature.
Modified version of phpunit, could accept custom options like this:
./phpuint-custom-option --custom var1=value1 --custom var2=value2 CustomOptionTest.php
And in the test, you can visit the custom options by accessing the super global variables $_SERVER
<?php
class CustomOptionTest extends PHPUnit_Framework_TestCase {
public function testCustomOption() {
$this->assertEquals('value1', $_SERVER['var1']);
$this->assertEquals('value2', $_SERVER['var2']);
}
}
and you can find my code here, and download the modified version here (by click the "view the full file" link on the page).
FYI. this article is the similar solution.