Codeception: Support for PHPUnit 6.0

[neufeind]

PHPUnit 6.0 was recently released. Make using 6.0 possible in the 2.2-branch (composer.json has <6.0 currently).

[samdark]

It has all the classes namespaced so it won't be easy...

[neufeind]

Just found another issue mentioning bigger changes in PHPUnit 6.0 which might make it hard (impossible?) to support 5.x and 6.x both. Though it would be great for other frameworks currently using Codeception (and maybe not really wanting to wait until 3.0).
https://github.com/Codeception/Codeception/issues/3972#issuecomment-277348788

[DavertMik]

Yep, technically it is impossible to support it in nearest future. According to PHPUnit changelog there is no good reason to do that, as it currently brings no new features. But yes, once we will be close to 3.0 we will switch to PHPUnit 6.x

[lastzero]

We are using PHPUnit 6, but due to Codeception we can not upgrade our frontend project and are stuck with 5.7 as it seems :(

I upgraded my own test-tools within a day, no issues. Just change the _ to \ basically.

So the official statement is: If you're using PHPUnit 6.0, wait for Codeception 3.0, right? If we want to use both before, we have to fork?

[lastzero]

Note: PHPUnit 5.7 offers a class name alias for forward compatibility. So the issue is not as big as it seems at first. Good work Sebastian :)

[orlangur]

bigger changes in PHPUnit 6.0 which might make it hard (impossible?) to support 5.x and 6.x both

It seems not possible easily to me with preserving current constraints:

"phpunit/phpunit": ">4.8.20 <6.0"

However, it's easy to support both 5.4+ and 6.0 due to forward-compatible changes.

For my projects I'm going to automate migration in scope of php-cs-fixer project first in order to reduce manual work (most massive changes are PHPUnit_Framework_TestCase -> phpunit\framework\TestCase and getMock -> createMock replacements). But it could be done pretty easily manually as well if you are in a hurry.

UPD: @lastzero, I started to write my comment before your finding :D

[DavertMik]

The thing is that Codeception uses slightly more than PHPUnit_Framework_TestCase. We still support PHPUnit 4.8 and it would be too risky to support 4.x and 6.x both. Even we create compatibility layers I'm not sure things won't break in 6.1, 6.2, etc.

And just the regular question: what features are in PHPUnit 6.0 that you currently miss in PHPUnit 5.7?

[orlangur]

First 6.x release with new features will be 6.1 :) I believe this issue is not about new features potentially offered by 6.x PHPUnit releases but about being prepared for the future. It would be pretty sad to sit on PHPUnit 5.x just because of testing framework of your choice.

We still support PHPUnit 4.8 and it would be too risky to support 4.x and 6.x both

Why still support PHPUnit 4.x when "PHPUnit 4.8 has reached End of Life as of February, 3 2017 and will no longer receive bug fixes"?

Even we create compatibility layers I'm not sure things won't break in 6.1, 6.2, etc.

I don't think so as PHPUnit is following SemVer, within 6.x some code may be marked as @deprecated but it will still work. You probably already have such experience with adopting framework to 5.4, 5.5, 5.6 PHPUnit versions and have an idea if there is a deviation between declaration and reality.

According to PHPUnit changelog there is no good reason to do that, as it currently brings no new features. But yes, once we will be close to 3.0 we will switch to PHPUnit 6.x

There is a good reason actually, you may be sure new tests you write are PHPUnit6-compatible when you write them in PHPUnit6 initially. There is no reason to switch directly to PHPUnit 6.x as both 5.4+ and 6.0 may be supported at the same time pretty easily.

With such a late PHPUnit6 compatibility introduction Codeception 3.0 migration path will be way steeper.

Make using 6.0 possible in the 2.2-branch

I don't this is a good idea though. What I think is the right compromise is PHPUnit6 compatibility introduction in master branch and then next minor release.

So, in Codeception 2.3 support of PHPUnit <5.4 can be dropped and support of PHPUnit 6.0 introduced. Those with tests relying on PHPUnit 4.x may continue using Codeception 2.2 without any issues (just like guys with Laravel4 applications are sticked to Codeception 2.1).

And in Codeception 3.0 it will be a good time for crucial things like dropping PHP and PHPUnit 5.x support.

Just my two cents, please correct me if I overlooked something.

[Naktibalda]

Codeception was written for and coexisted for a long time with PHPUnit 4.
Support for PHPUnit 5 was implemented by adding a few class aliases to https://github.com/Codeception/Codeception/blob/2.2/shim.php

Keeping up with breaking changes every year is a challenge. We have no obligation to support every version of PHPUnit - we could even skip v6 and wait for v7.

You are welcome to implement support for PHPUnit 6 in backwards compatible manner and make a pull request.

[DavertMik]

@orlangur ok, I got your point; writing tests in PHPUnit 6 style. Can this be done just by adding forward compatibility layer from PHPUnit 5.6 using class_alias?

If you want you can try to implement PHPUnit 6 support and make a PR as @Naktibalda proposed.

[orlangur]

We have no obligation to support every version of PHPUnit - we could even skip v6 and wait for v7.

Why not drop PHPUnit 4 support then if it reached End of Life already?

Can this be done just by adding forward compatibility layer from PHPUnit 5.6 using class_alias?

Most likely yes, more than that we can always take a functionality introduced during some v1..v2 PHPUnit development and add it to a compatibility layer on our side.

Just that it brings more problems than value as to me. There is no reason to support every ancient version of every component even if there is only one supported Codeception version at a time.

According to my understanding Sebastian already did an excellent work on forward-compatibility in PHPUnit 5.x and adding some hacks to preserve PHPUnit 4.x compatibility is a waste of time.

I'm OK to prepare a PR introducing PHPUnit 6 compatibility and changing phpunit constraint to >=5.4 <6.1 if I can rely on existing automated tests and not checking all the codes for potential breakage. If you don't want to make migration path to Codeception 3 smoother and just suddenly drop PHP/PHPUnit 5.x support at some point, I'm OK with that too, just don't want to take part in this :)

[Naktibalda]

Dropping support for PHP 5.4 and 5.5 and PHPUnit 4 in the next minor or major version is fine.
@DavertMik wants to do something major for 3.0, but if he is too busy with other stuff, PHPUnit 6 support could be released as 2.3.0

[orlangur]

@Naktibalda ok, thanks, that's nice to hear :) I'll try to elaborate something on PHPUnit6 compatibility this week.

For 3.0 we could probably drop PHPUnit5 and PHP 5.6 support, PHPUnit6 compatibility by itself does not require such a huge step forward, so, I believe it would be a good thing to be adopted earlier in 2.3.0.

[Naktibalda]

Implemented in 2.2 branch #4142