@runClassInSeparateProcess

[JasperHorn]

This is a feature request for a way to mark a class to be run in a separate process. This would be a step between having each test run in its own process and the default of having everything run in the same process.

This is most interesting when using separate processes for a technical reason (e.g. I'm testing code that generates php classes) and inheritance is involved. The idea is that it's often much easier to make sure no two tests within the same class run into problems (e.g. not reusing class names for the generated classes between tests) than to make sure the same test run by different children doesn't run into problems (here, it would be working get_class($this) into the class names for generated classes). While the latter is often possible, it will often lead to much less readable code.

The benefit of using this would be in the fact that the performance penalty a process per class incurs is much less severe than the performance penalty for a process per test, especially when taken relative to the amount of time spent running the actual tests.

[sun]

👍 Looking for exactly this, too.

The idea of @runClassInSeparateProcess pretty much maps to setUpBeforeClass().

It is useful when your bootstrap.php script is very expensive, so rebooting just once per class would dramatically improve performance.

It is also useful if you do not control the actual tests that are executed as part of a test suite. — That might sound weird, but it is the case for e.g. tests of Drupal contributed/custom/add-on module extensions, which are executed as part of Drupal's central PHPUnit configuration (because all contributed modules depend on Drupal core code, and because they can have interdependencies between each other; correctly setting up the class loader and configuration for that is complex, so that is set up only once). In this case, process isolation per class ensures that a potential fatal error doesn't break the entire test suite.

[whatthejeff]

👍 I would accept a PR for this.

[sebastianbergmann]

Dear contributor,

let me start by apologizing for not commenting and/or working on the issue you have reported or merging the pull request you have sent sooner.

PHPUnit 5.0 was released today. And today I am closing all open bug reports and pull requests for PHPUnit and its dependencies that I maintain. Please do not interpret the closing of this ticket as an insult or a lack of interest in your problem. I am sorry for any inconvenience this may cause.

If the topic of this ticket is still relevant then please open a new ticket or send a new pull request. If your ticket or pull request is about a defect then please check whether the issue still exists in PHPUnit 4.8 (which will received bug fixes until August 2016). If your ticket or pull request is about a new feature then please port your patch PHPUnit 5.0 before sending a new pull request.

I hope that today's extreme backlog grooming will allow me to respond to bug reports and pull requests in a more timely manner in the future.

Thank you for your understanding,
Sebastian