Remove instantiated (child process) objects from TestFailure #1352
Conversation
…est class upon failure.
Catching a PHPUnit exception and rethrowing it as a non-PHPUnit exception does not make any sense.
| * the parent would break the intended encapsulation of process isolation. | ||
| * | ||
| * @see http://fabien.potencier.org/article/9/php-serialization-stack-traces-and-exceptions | ||
| * |
There was a problem hiding this comment.
To clarify: I'm aware that PHPUnit's current code contains almost no developer documentation at this point. I don't know whether that has been an informed decision or whether it's just caused by laziness.
However, in case of deeply internal PHP gems like this, it's guaranteed that every contributor who studies the code will have no idea why PHPUnit is doing what it's doing (unless she's familiar with the problem space already, which is very unlikely). Having to grep commit logs first, just because some code happens to resolve a complex problem space, presents a barrier to contribution. That's to be avoided.
Therefore, it's best to make it easy for new contributors to understand (at minimum) architecture-level considerations and pitfalls. Doing so is a qualified and verified approach to increase contributions.
(In fact, being deeply involved in one of the largest and most thriving FOSS communities, I won't hesitate to say that this is the key to sustainable success, specifically with regard to the quality and amount of user contributions.)
There was a problem hiding this comment.
The lack of developer documentation likely stems from the fact that PHPUnit was developed and maintained by a single developer for most of its history. I find notes like this very helpful.
Remove instantiated (child process) objects from TestFailure
|
Very nice addition, @sun! Thanks for all your hard work :) |
Resolves #1351
Let's keep communication centralized over there.