Q: handling of 'void' return type on TestCase::fail and TestCase::run

[gggeek]

In some of my own tests, which have been executed so far on php 5.5-7.4 (via phunit 4 and 5), I have reimplemented the fail and run methods in my TestCase subclass.
I am now trying to make those same tests run as well on php 8.0, via phpunit 8 and this package.
However, when trying to run the tests, I hit the same snag as with the setUp method, namely that the return type of my methods is not compatible with the one from the grand-parent class.
Any suggestion on how to fix this?
The easiest one seems to be to implement in PHPUnitPolyfills\TestCases\TestCase methods named f.e. _run and _fail, which work the same way as _setup, but it might be considered hackish...

[gggeek]

I am trying to implement this in a subclass of TestCase as part of my test code. So far, I managed to get the new class autoloaded from two separate files to be compliant with the post-phpunit 8 return types, but I am now struggling with the typehinting for PHPUnit_Framework_TestResult...

[gggeek]

Update: once I fixed the problem with PHPUnit_Framework_TestResult, I had to alias as well PHPUnit\Extensions\SeleniumCommon\RemoteCoverage to PHPUnit_Extensions_SeleniumCommon_RemoteCoverage.

So far it seems that, even when using PHPUnit-Polyfills, it is not a trivial process to make a testsuite which does "advanced" usage of PhpUnit be compatible with widely-different PhpUnit versions (5 and 8 in my case - I just dropped 4 because of headaches it gave to Composer).

I wonder if it is worth going down the rabbit hole of trying to alias more (or even all) classes and methods...

ps my code: https://github.com/gggeek/phpxmlrpc/blob/master/tests/PolyfillTestCase.php

[jrfnl]

@gggeek Hiya, I've been thinking about your question and haven't really got an answer yet.

As a general rule of thumb, I've stuck to handling "public API" parts, which for the TestCase translates to "methods which are intended to and expected to be overloaded".
fail() and run() are not really in that category, so that feels more like a usecase which - as you've done - should be handled by extending the TestCase(s) provided by this package in a specific test suite which needs to overload those methods.

But to be fair, I haven't had the time to dig into the source to make a proper assessment.

It also begs the question: do those methods really need to be overloaded ? Or is there another way to handle what you are trying to do ? Possibly via a TestListener or other supported way to extend PHPUnit ?

[gggeek]

@jrfnl thanks for the suggestion!
I have to admit that the testsuite in question - and my knowledge of phpunit api best and practices - is rusty, as it comes from the very darkest age of php (suffice it to say that it started out with a fully bundled copy of phpunit 1.3 from 2005...).

Now, I have taken a look at the documentation for phpunit v5 (which afaik is the oldest version supported by PHPUnit-Polyfills), and there seems to be a couple of officially sanctioned ways to extend tests: PHPUnit_Extensions_TestDecorator and PHPUnit_Framework_TestListener. [ ref: https://devdocs.io/phpunit~5/extending-phpunit ]
The former has been apparently dropped in phpunit 6, while the latter seems to require a registration in phpunit's xml configuration file (jn addition of course to the interface having been renamed and namespaced, and having gotten return types added to its methods. That, and the arguments passed to 'hooks listeners' are quite different from the ones passed to TestListeners...)

In short: it seems that there is no easy way to write portable test code which uses a supported way to extend PHPUnit.
Which makes me think that it would make sense for PHPUnit-Polyfills to try to fill that gap.
As to whether this is possible without a humongous amount of code, and kludges in the resulting API emulation, I don't know...

[jrfnl]

phpunit v5 (which afaik is the oldest version supported by PHPUnit-Polyfills),

Actually, version 0.2.0 of this package added support for PHPUnit 4, though only for the very last release 4.8.36.

PHPUnit_Framework_TestListener. ... the latter seems to require a registration in phpunit's xml configuration file (jn addition of course to the interface having been renamed and namespaced, and having gotten return types added to its methods. That, and the arguments passed to 'hooks listeners' are quite different from the ones passed to TestListeners...)

And you may also like to hear that version 0.2.0 also contains a PHPUnit cross-version TestListenerDefaultImplementation.

Refs:

• https://github.com/Yoast/PHPUnit-Polyfills/releases/tag/0.2.0
• https://github.com/Yoast/PHPUnit-Polyfills/tree/develop#testlistener

Which makes me think that it would make sense for PHPUnit-Polyfills to try to fill that gap.

Exactly what I've been trying to do ;-)

[gggeek]

Lovely!
I'll give TestListenerDefaultImplementation a spin when I manage to spare some time for tests improvements.

[sebastianbergmann]

If setUp() and tearDown() are a problem because of :void then simply do not use these names. Use different names and annotate the methods with @before and @after, respectively.

[jrfnl]

@sebastianbergmann Thanks for your input.

If setUp() and tearDown() are a problem because of :void then simply do not use these names. Use different names and annotate the methods with @before and @after, respectively.

That problem has already been solved by offering two different template TestCases in this package, one of which is showing the @before and @after solution, the other using snake case method names and calling those from the real setUp() et al.

See: https://github.com/Yoast/PHPUnit-Polyfills#testcases

Along the same vein, the TestListenerDefaultImplementation trait offered in this package works around the type declarations via snake_case method names.

See: https://github.com/Yoast/PHPUnit-Polyfills#testlistener