PHPUnit 6 compatiblity #93

aik099 · 2017-07-26T06:51:49Z

PHPUnit 6 release changed PHPUnit_Framework_TestCase class into \PHPUnit\Framework\TestCase and therefore any extends PHPUnit_Framework_TestCase in this project now fails with this error:

PHP Fatal error:  Class 'PHPUnit_Framework_TestCase' not found in /var/www/html/vendor/aik099/phpunit-mink/library/aik099/PHPUnit/BrowserTestCase.php on line 33

Maybe https://github.com/minkphp/phpunit-mink/blob/master/library/aik099/PHPUnit/AbstractPHPUnitCompatibilityTestCase.php can be updated to not only support PHPUnit 5 and 4, but also PHPUnit 6.

The text was updated successfully, but these errors were encountered:

aik099 · 2017-07-26T06:54:46Z

Hopefully all public API of test case classes remained the same and extending them from different parent class would do the trick.

robertfausk · 2017-07-27T07:27:57Z

I'll give it a try today. Should not be that hard.

aik099 · 2017-07-27T08:23:28Z

You can also try changing the .travis.yml so that PHPUnit supplied by Travis CI could be used. This would automatically test that each of PHPUnit versions (4.x, 5.x, 6.x) are still working. Right now we're forced to use PHPUnit 4.x on Travis CI if I'm not mistaken.

robertfausk · 2017-07-28T16:28:41Z

Yep. Right now it's PHPUNIT 4.8 for all PHP versions.

According to https://docs.travis-ci.com/user/languages/php/#Choosing-PHP-versions-to-test-against travis uses installed version found in $COMPOSER_BIN_DIR/phpunit

I would suggest do add a composer update phpunit/phpunit in before_script section and also test PHP 7.1.

# .travis.yml
...
php:
    - 7.0
    - 7.1    # added
    - hhvm
...
install:
    - composer update phpunit/phpunit    # added
    - composer require satooshi/php-coveralls:^1.0 --dev

This would result in following matrix:

PHP	PHPUNIT
5.3	4.8
5.4	4.8
5.5	4.8
5.6	5.7
7.0	6.2
7.1	6.2

With this setup the .travis.yml wouldn't grow that much. What do you think?

Btw: Why is 7.0 marked as allow_failures? Do you mind if it's not marked as allow_failures anymore for 7.0 and 7.1?

aik099 · 2017-07-29T06:48:28Z

That would 2 different PRs:

use PHPUnit for used PHP version
add support for PHP 7.1 and move out PHP 7.0 from allow_failures

Btw: Why is 7.0 marked as allow_failures? Do you mind if it's not marked as allow_failures anymore for 7.0 and 7.1?

Because at the time .travis.yml was created PHP 7 wasn't even released or contained many bugs.

robertfausk · 2017-07-29T09:02:14Z

I think there will be 3 PRs:

use PHPUnit for used PHP version
PHPUnit 6 compatiblity (currently there is only PHPUnit ~4|~5 in composer.json)
add support for PHP 7.1 and move out PHP 7.0 from allow_failures

robertfausk · 2017-07-29T11:08:16Z

Hmmm. I currently stuck with following problem:
The library code extends PHPUnit classes.
The test code extends PHPUnit classes.

@aik099 Do you know if it's possible to execute tests with e.g. PHPUnit 4.8 while library code uses a different PHPUnit version e.g. PHPUnit 6.2?
If this is not possible then also test code has to be adopted to work with all PHPUnit versions (4, 5 and 6)

Additionally mockery currently doesn't support PHPUnit 6 yet PHPUnit 6 support mockery/mockery#728 (e.g. TestListener of mockery doesn't work)
There are many type hint conflicts in methods and class constructors which need to be solved

@aik099 What do you think about a new major release for PHPUnit 6 support? This would result in cleaner code (less if else constructs).

aik099 · 2017-07-29T11:32:25Z

Hmmm. I currently stuck with following problem:
The library code extends PHPUnit classes.
The test code extends PHPUnit classes.

Then we need to:

update AbstractPHPUnitCompatibilityTestCase class to support PHPUnit 6 (hopefully other method signatures match)
add analog of AbstractPHPUnitCompatibilityTestCase but for test suite only with same functionality.

... Do you know if it's possible to execute tests with e.g. PHPUnit 4.8 while library code uses a different PHPUnit version e.g. PHPUnit 6.2?

I guess no, because at time of PHPUnit 4.x development it wasn't aware that different class names will be used in PHPUnit 6.x.

There are many type hint conflicts in methods and class constructors which need to be solved

Any examples?

... What do you think about a new major release for PHPUnit 6 support? This would result in cleaner code (less if else constructs).

You mean drop support for PHPUnit 4.x and 5.x? If that is so, then I'm against that. I don't want anyone to force upgrade to PHPUnit 6 to get latest features of this library.

robertfausk · 2017-07-29T12:01:03Z

Any examples?

all extends in classes relying on PHPUnit classes => would solve this with an abstract class;
phpunit-mink/library/aik099/PHPUnit/Event/TestEndedEvent.php

Line 36 in 68b9443

\PHPUnit_Framework_TestResult $test_result,

phpunit-mink/library/aik099/PHPUnit/TestSuite/AbstractTestSuite.php

Line 95 in 68b9443

if ( $test instanceof \PHPUnit_Framework_TestSuite_DataProvider ) {

phpunit-mink/library/aik099/PHPUnit/TestSuite/AbstractTestSuite.php

Line 95 in 68b9443

if ( $test instanceof \PHPUnit_Framework_TestSuite_DataProvider ) {

phpunit-mink/library/aik099/PHPUnit/TestSuite/BrowserTestSuite.php

Line 57 in 68b9443

if ( $test instanceof \PHPUnit_Framework_TestSuite_DataProvider ) {

phpunit-mink/tests/aik099/PHPUnit/BrowserTestCaseTest.php

Line 302 in 68b9443

$this->assertInstanceOf('\\PHPUnit_Framework_TestResult', $test_case->run());

etc.

if ( $test instanceof \PHPUnit_Framework_TestSuite_DataProvider ) {

could become

if ( $test instanceof \PHPUnit_Framework_TestSuite_DataProvider || $test instanceof \PHPUnit\Framework\DataProviderTestSuite  ) {

or something like

if ( $test instanceof PHPUnitCompatibilityClassNames::DATA_PROVIDER ) {
# in PHPUnitCompatibilityClassNames the const DATA_PROVIDER will be set by PHPUnit version

You mean drop support for PHPUnit 4.x and 5.x? If that is so, then I'm against that. I don't want anyone to force upgrade to PHPUnit 6 to get latest features of this library.

Another possibility would be to maintain two branches. One with PHPUnit 4.x and 5.x and the other one with PHPUnit 6.x. But I fear it's to much overhead?!

aik099 · 2017-07-29T12:09:32Z

phpunit-mink/library/aik099/PHPUnit/Event/TestEndedEvent.php

Line 36 in 68b9443

\PHPUnit_Framework_TestResult $test_result,

I see no way to make type hints compatible with both PHPUnit 6.x and below.

Another possibility would be to maintain two branches. One with PHPUnit 4.x and 5.x and the other one with PHPUnit 6.x. But I fear it's to much overhead?!

That would be too much indeed.

aik099 · 2017-07-29T12:12:07Z

Maybe we can create polyfill the way, that we create PHPUnit 6.x class by extending from PHPUnit 5.x/5.x class. Then in code we use PHPUnit 6 classes in all places. Include polyfills in test suite bootstrap file.

Not sure how PhpStorm test runner would react to such trick though.

stof · 2017-07-29T12:14:18Z

for the testsuite, your don't need anything special: just use the namespaced classes (and bump the min PHPUnit version to 4.8.35 as older 4.8 releases don't have them)

aik099 · 2017-07-29T12:19:43Z

I thought, that namespaced classes were only added in PHPUnit 6.x.

stof · 2017-07-29T12:23:01Z

Well, the namespace version of a few classes (the one used when writing tests rather than when extending PHPUnit) have been shipped in 4.8.35 and in 5.4.3+, to allow users to migrate their testsuites progressively (before 6.0, these classes are extending the kind of polyfills you described above btw).
For internal classes, there is no forward-compatibility layer.

aik099 · 2017-07-29T12:29:11Z

Nice. Then @robertfausk could make use of them.

robertfausk · 2017-07-29T12:35:22Z

I will give it a try after #94 has finished build and is merged.
This will result in another PR with bump PHPUnit version to 4.8.35+ or 5.4.3+.

phpunit-mink/library/aik099/PHPUnit/Event/TestEndedEvent.php

Line 36 in 68b9443

\PHPUnit_Framework_TestResult $test_result,

I see no way to make type hints compatible with both PHPUnit 6.x and below.

Same solution like AbstractPHPUnitCompatibilityTestCase should do the trick.

aik099 · 2018-10-09T06:13:18Z

So what's the state of this?

Considering how quick PHPUnit is doing it's releases, that change method signatures/visibility, that we're using I'm proposing to:

create 2.x branch from current master and tag all further 2.x releases, that needs PHPUnit 4.x, 5.x from there
in the master branch remove PHPUnit 4.x, 5.x compatibility layer (or transform it to support PHPUnit 6.x, 7.x) and update code to work with PHPUnit 6.x, 7.x

zann1x · 2019-10-01T11:32:38Z

So now that another year passed... can we expect any progress on this issue in the near future?

aik099 · 2019-10-01T13:18:52Z

If somebody is using this, then a PR is welcome. My personal choice is avoid using new PHPUnit version, since IMO they don't bring anything new except BC breaks. The only things developer need are assert... methods and they're the same (maybe some minor new ones are added).

zann1x · 2019-10-02T07:50:08Z

Well partly true. Some PHP frameworks do require a PHPUnit version of 6 or higher to work. That makes this library unusable with them.

aik099 · 2019-10-02T08:35:28Z

We're also having same problem in Mink library itself.

Maybe a new project like minkphp/phpunit-bc-layer would solve the problem. Idea is to have single project, that would compensate for BC breaks and we'll extend our TestSuite/TestCase/DataProvider classes from it instead.

aik099 · 2024-03-13T08:16:44Z

The PHPUnit-Mink v2.3.0 release added support for all PHPUnit versions up to 9.x.

aik099 added type-bug type-enhancement and removed type-bug labels Jul 26, 2017

aik099 mentioned this issue Jul 26, 2017

qa-tools/phpunit-extension not working with PHPUnit 6.x qa-tools/qa-tools#197

Closed

robertfausk mentioned this issue Jul 29, 2017

use PHPUnit for used PHP version #94

Merged

robertfausk mentioned this issue Aug 9, 2017

Bump PHPUnit version to 4.8.35+ or 5.4.3+ and use phpunit namespaces #95

Merged

aik099 mentioned this issue Sep 5, 2017

Argument 1 passed to BrowserTestCase::onNotSuccessfulTestCompatibilized() must be an instance of Exception #97

Closed

aik099 mentioned this issue May 12, 2018

Update requirements for classes after upgrade PHPUnit to >= 6 #100

Closed

aik099 self-assigned this Oct 9, 2018

aik099 closed this as completed Mar 13, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PHPUnit 6 compatiblity #93

PHPUnit 6 compatiblity #93

aik099 commented Jul 26, 2017

aik099 commented Jul 26, 2017 •

edited

robertfausk commented Jul 27, 2017 •

edited

aik099 commented Jul 27, 2017

robertfausk commented Jul 28, 2017

aik099 commented Jul 29, 2017

robertfausk commented Jul 29, 2017

robertfausk commented Jul 29, 2017

aik099 commented Jul 29, 2017 •

edited

robertfausk commented Jul 29, 2017

aik099 commented Jul 29, 2017 •

edited

aik099 commented Jul 29, 2017

stof commented Jul 29, 2017

aik099 commented Jul 29, 2017

stof commented Jul 29, 2017

aik099 commented Jul 29, 2017

robertfausk commented Jul 29, 2017

aik099 commented Oct 9, 2018

zann1x commented Oct 1, 2019

aik099 commented Oct 1, 2019

zann1x commented Oct 2, 2019

aik099 commented Oct 2, 2019

aik099 commented Mar 13, 2024

PHPUnit 6 compatiblity #93

PHPUnit 6 compatiblity #93

Comments

aik099 commented Jul 26, 2017

aik099 commented Jul 26, 2017 • edited

robertfausk commented Jul 27, 2017 • edited

aik099 commented Jul 27, 2017

robertfausk commented Jul 28, 2017

aik099 commented Jul 29, 2017

robertfausk commented Jul 29, 2017

robertfausk commented Jul 29, 2017

aik099 commented Jul 29, 2017 • edited

robertfausk commented Jul 29, 2017

aik099 commented Jul 29, 2017 • edited

aik099 commented Jul 29, 2017

stof commented Jul 29, 2017

aik099 commented Jul 29, 2017

stof commented Jul 29, 2017

aik099 commented Jul 29, 2017

robertfausk commented Jul 29, 2017

aik099 commented Oct 9, 2018

zann1x commented Oct 1, 2019

aik099 commented Oct 1, 2019

zann1x commented Oct 2, 2019

aik099 commented Oct 2, 2019

aik099 commented Mar 13, 2024

aik099 commented Jul 26, 2017 •

edited

robertfausk commented Jul 27, 2017 •

edited

aik099 commented Jul 29, 2017 •

edited

aik099 commented Jul 29, 2017 •

edited