Silverstripe-framework: PHPUnit 5.7 doesn't support PHP 7.4

[sminnee]

Recent build breakages have highlighted that the mocking system of PHPUnit 5.7 (well, phpunit-mock-objects 3.4) uses an API that was documented as deprecated in PHP 7.1 and started throwing deprecation errors in PHP 7.1

PHPUnit 8 solves that, but we're not using that in SilverStripe 4, and although we might be able to get away with using it in SS 4.5+, now that we've dropped php 5.6 / 7.10, it likely has breaking API changes that would force SS4 test suites to be rewritten, which wouldn't be okay.

Possible solutions:

1. Patch phpunit-mock-objects, hopefully via a PR to the upstream project, or by creating a fork of our own
2. Drop support for php 7.4, meaning that SS4 has an externally driven end-date of 6 Dec 2021

I'm not happy about the 2nd as this caused us a lot of pain with SS3. So I think we need to patch php-mock-objects. Ideally we can bump up to php-mock-objects 4, 5, or 6 breaking the APIs we use and Sebastian will accept a PR to those more recent versions and produce a stable tag. But failing that we will probably want to publish a fork.

Pull Requests

• [x] https://github.com/silverstripe/silverstripe-framework/pull/9063

[sminnee]

The mock-objects repo is readonly and so we'd need to publish a fork to address this.

[sminnee]

We may need to disable the php7.4 build until this ticket is addressed, then, @maxime-rainville...

[robbieaverill]

We'd probably need to run a fork of it, since PHPUnit 5.x has been out of support for almost 18 months now

[maxime-rainville]

9063 should still run the 7.4 build, but allow it to fail without failing the entire build.

[maxime-rainville]

Forking mock-objects feels dirty, but I don't see any other viable alternative.

[sminnee]

I've set up https://github.com/sminnee/phpunit-mock-objects and it's got a branch with the fix in place; should I publish sminnee/phpunit-mock-objects that provides phpunit/phpunit-mock-objects:3.4.5? I'm happy to be "the maintainer", such as it is.

[robbieaverill]

Before we continue, is this something that every module and project will need to opt in to using when they require phpunit 5.7? If so, that seems totally un-ideal to me. We may be able to hack in a class_alias() based replacement for a shim somewhere in framework instead?

[maxime-rainville]

Wouldn't we better to have it under the open sausage org? That way if we need to update it, we won't have to annoy you all the time.

[sminnee]

If you want to take responsibility for it then it should be github.com/silverstripe, IMO. Team repos should never publish anything.

[sminnee]

Or it could be maxime. But I can give you commit rights on the sminnee repo if you want

[maxime-rainville]

Actually is this something we'll expect regular dev to use as well? Presumably, many outside project use a set up relatively similar to ours for testing, so they'll run in the same issue.

[sminnee]

Before we continue, is this something that every module and project will need to opt in to using when they require phpunit 5.7? If so, that seems totally un-ideal to me. We may be able to hack in a class_alias() based replacement for a shim somewhere in framework instead?

It only applies to projects using the PHPUnit mock system that want to run on PHP 7.4.

[robbieaverill]

It only applies to projects using the PHPUnit mock system that want to run on PHP 7.4.

Just checking - by this do you mean any user code that uses $this->createMock() in a unit test?

[sminnee]

Or $this->getMockBuilder() as EmailTest does for example, but yeah that's the idea.

[robbieaverill]

I'd say that'd be pretty widespread in the community. Let's see what the author replies to your email with, and if there's no interest then I think we should try a hacky shim in framework rather than a package fork that everybody would need to remember to install.

[robbieaverill]

Noting that this is the crux of @sminnee's patch, for reference: https://github.com/sminnee/phpunit-mock-objects/commit/64650615dbde4041483cab2609293c3da3bd7042