Allow a test to identify whether it runs in isolation

[sun]

A custom setup of test fixtures may use the new PHPUnit_Framework_TestCase::isTestInIsolation() method to determine whether to skip additional performance optimizations that only make sense if multiple tests are executed in the same process.

The tests I'm currently working on need to boot up application framework objects that are very expensive to (re-)build (a full-stack Symfony Kernel/ContainerBuilder). In my case, all test methods of a single test class are always initialized in the same way, so precompiling it once and cloning it for every test method dramatically improved performance (related: symfony/symfony#11422). — However, that obviously doesn't make sense in case only one test is executed in isolation.

It is possible to identify this already, but the $isInIsolation property is private, so it's clunky:

  protected function isTestInIsolation() {
    return function_exists('__phpunit_run_isolated_test');
  }

In light of #950, I named the new method isTestInIsolation() instead of isInIsolation().

As this is a minor addition, my hope is to get it into the next 4.1.5 stable.

[sun]

Hm, weird failure on PHP 5.3.3:

/home/travis/build.sh: line 217: 2178 Segmentation fault ./phpunit --configuration ./build/travis-ci.xml

Already happened when travis tested the branch in my repo… can't see why this change would cause that on 5.3.3, anyone any ideas?

[whatthejeff]

anyone any ideas?

Haha, no idea. That's a strange one.

[sun]

Somehow I'm not able to trigger a re-test on travis, so I just force-rebased + pushed the branch.

[whatthejeff]

@sun This needs to go into master since it's not a bug fix.

[sun]

Oh wow. I didn't notice that all the tests in tests/Framework/TestCaseTest are instantiating new, local TestCase classes, and only those separate instances are actually run...

That makes… some level of sense, because the expected state/behavior of the TestCase class itself can't really be tested while executing the TestCase class itself. OTOH, I wonder why there isn't a single WrapperTestCaseTest class that executes all tests of a "child" TestCaseTest class…

I assume the segmentation fault is the only reason for why we're still testing against PHP 5.3.3... (which is EOL either way)

re: master: ok, will do.

[whatthejeff]

I assume the segmentation fault is the only reason for why we're still testing against PHP 5.3.3... (which is EOL either way)

We had an email chain about this with some framework maintainers a few months ago. The consensus was that everyone wanted to continue supporting 5.3 for a bit longer.

[sun]

continue supporting 5.3 for a bit longer

Note that the segmentation fault only happened on the explicit build on 5.3.3 (2010-07-22). The more current 5.3[.27] passed fine.