support phpunit 6
garak opened this issue · comments
Thanks for posting this issue 👍 This is definitely something we should support. However, since PHPUnit 5 does not provide forward-compatibility support for custom printers we would need to maintain a separate branch, which is a bit awkward.
Alternatively, we could submit a PR to PHPUnit to provide the aforementioned forward-compatibility. However, I see you already submitted a similar request which was denied, so I am dubious about our chances of success here.
It looks like the only class you need to support is PHPUnit_TextUI_ResultPrinter (excluding your own tests, that you can handle easily).
So, maybe the best solution could be that you add a BC layer, defining (if not already defined) such class for phpunit 5
Actually we require several more classes than just the ResultPrinter:
\PHPUnit_TextUI_ResultPrinter\PHPUnit_Framework_Test\PHPUnit_Util_Test\PHPUnit_Framework_AssertionFailedError
I am not sure we want to support a forward-compatibility layer locally, but it is an interesting option if @sebastianbergmann declines our request to include this in his 5.x branch.
As you mentioned above, he already declined.
Symfony went on a similar path to support both phpunit 5 and 6, see symfony/symfony#21694
I think you're right, there's no point even proposing to extend the forward-compatibility layer just to satisfy our requirements. Even if we could gain support for PHPUnit_TextUI_ResultPrinter, how can we justify PHPUnit_Util_Test and PHPUnit_Framework_AssertionFailedError? Where do we draw the line?
The more I think about it, the more I like the idea of including such a compatibility layer in this project. My only concern is if the 5.x branch diverges from the 6.x branch, but judging by the way Bergmann typically tags both bugs and enhancements with both 5.x and 6.x tags, I am hopeful they will not diverge significantly and this will prove to be a better solution than maintaining two branches.
Do you want to work on this issue or do you prefer to let someone else implement it?
Of course, I can arrange a PR tomorrow
I look forward to it.
Sorry, I tried hard to find a solution involving both 5 and 6 at the same time, but it looks like it's more complicated than expected.
I'm afraid that the double branch is the final solution
That is unfortunate, but can you share more details of the problems you found? What is the main reason we cannot support PHPUnit 5 and 6 printers at the same time?
You can see the branch I worked on here: https://github.com/garak/PHPUnit-Immediate-Exception-Printer/tree/phpunit6
OK, I created two new branches, PHPUnit-5 and PHPUnit-6. You can work on PHPUnit 6 support separately and not have to worry about trying to support the old version at the same time. This way you can create your PR against the PHPUnit-6 branch and we will tag it with a new major version, e.g. 🏷️ 2.0.0.
On second thoughts, I think we should do some more investigation. It seems you tried to duplicate the printer to support both versions, which I do not want to do. But what about creating polyfills for missing classes instead? e.g.
if (!class_exists('PHPUnit_Framework_Test') && class_exists('PHPUnit\Framework\Test')) {
class PHPUnit_Framework_Test extends PHPUnit\Framework\Test {}
}And where you should put such code?
Oh, I see the problem, since we rely on PHPUnit to start our program but we don't know which version the user has loaded 😅
How about if our printer extends a proxy printer, e.g.
class ImmediateExceptionPrinter extends ResultPrinterProxyThen we implement ResultPrinterProxy as in the following example.
// PHPUnit 5.
if (class_exists(PHPUnit_TextUI_ResultPrinter::class)) {
class ResultPrinterProxy extends PHPUnit_TextUI_ResultPrinter {}
} // PHPUnit 6.
elseif (class_exists(ResultPrinter::class)) {
class ResultPrinterProxy extends ResultPrinter {}
// Do other class aliasing here...
} else {
throw new PHPUnitNotFoundException;
}Problem is with type hinting in methods
What if we just get rid of the type hints? We can still type hint in the docblocks for code completion in our editors, but we don't let PHP type check the parameters any more.
It looks like a poor solution to me, we'd give up to an important check just for the sake of multiple version supporting. I think that the double branch would be a better solution
Why is the type information an important check?
Because it's not just an hinting, it's also a check that the passed object is the expected one. Without such ckeck, you decrease the control on application flow
Don't you think PHPUnit would be pretty broken if it stopped sending the correct objects? It is not our job to ensure PHPUnit works, that is the job of PHPUnit, which already has such tests to ensure correct operation. We can assume the correct objects are passed, but even if they are not, I would expect our functional tests to fail anyway. Ergo the type check really isn't needed.
But we're extending a class that is implementing an interface, I'm pretty sure that we can't remove type hinting anyway, since it would break the interface itself
PHPUnit 6 support is available as of 🏷 1.1.0.