Problem/Motivation
Deprecation messages are not being unserialised since #3156998: Using @requires extension_name in PHPUnit unit tests fails if extension is not present.
See https://www.drupal.org/pift-ci-job/1774572
Steps to reproduce
- Apply https://www.drupal.org/files/issues/2020-07-29/3160405-11.patch
- Run test core/modules/comment/tests/src/Functional/CommentAnonymousTest.php
Proposed resolution
This can only be properly fixed upstream in Symfony because of how it decides to unserialise deprecation information in \Symfony\Bridge\PhpUnit\DeprecationErrorHandler\Deprecation
It's looking for a class starting with Symfony\Bridge\PhpUnit\Legacy\SymfonyTestsListenerFor after it has ignored all the PHPUnit classes. We need to change:
if (isset($line['class']) && 0 === strpos($line['class'], SymfonyTestsListenerFor::class)) {
to
if (isset($line['class']) && is_subclass_of($line['class'], TestListener::class)) {
Remaining tasks
Decide whether we'll use this fix or wait for upstream - https://github.com/symfony/symfony/pull/37708 https://github.com/symfony/symfony/pull/38031
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet
N/a
Comment | File | Size | Author |
---|---|---|---|
#14 | 3162403-2-14.patch | 2.31 KB | alexpott |
#3 | 3162403-3.patch | 11.59 KB | alexpott |
#3 | 2-3-interdiff.txt | 872 bytes | alexpott |
#2 | 3162403-2.patch | 11.57 KB | alexpott |
Comments
Comment #2
alexpottAs we don't support phpt testing we can't write a test for this. So it needs manual testing. At best DrupalCI can confirm that we've not broken the positive deprecation tests with this approach.
Comment #3
alexpottKeeping aligned with what's happening upstream.
Tested locally by applying https://www.drupal.org/files/issues/2020-07-29/3160405-11.patch and running
core/modules/comment/tests/src/Functional/CommentAnonymousTest.php
... the new approach works just great - you seeAs opposed to serialised guff.
Comment #4
mondrakeLooks like upstream is planning on merging the PR for next release (was tagged), so I suggest to wait, the bug is noisy printout but functionally all is good.
Comment #5
mondrakeUpstream https://github.com/symfony/symfony/pull/37708 was merged on Aug 23, 2020, so Symfony 5.1.4 should have it.
Comment #6
mondrakeFiled #3168107: Bump composer.json symfony/phpunit-bridge constraint to ^5.1.4.
Comment #7
catchComment #8
andypostQueued to test on top of commited
Comment #9
alexpottUnfortunately the PR only made it into the master branch and not the 5.1 branch of Symfony so we still have an issue. Once that PR lands in a SF release it should automatically fix this issue - so that this issue can become about fixing the composer.json to a version the works 100% correctly.
Comment #10
alexpotthttps://github.com/symfony/symfony/pull/38031 exists to merge the change to 5.1
Comment #11
alexpottSo now we're waiting on the next SF5 release as the upstream fix has now been merged to the SF5 branch.
Comment #12
mondrakeThanks @alexpott - upstream merged into 5.x, but it will probably be a month's time before 5.1.6 will be out. Postponing in the meantime.
Edit - xpost with #11
Comment #13
mondrake5.1.6 released today.
Comment #14
alexpottHere's the patch to update symfony phpunit - I didn't bump the constraint because whilst the upgrade fixes a bug I don't think bumping is warranted.
Comment #15
mondrake#14 agreed. Tested in a TravisCI build with a contrib module that throws deprecations, https://travis-ci.org/github/mondrake/d8-unit/builds/731228328, OK.
RTBC
Comment #17
catchCommitted 0774f68 and pushed to 9.1.x. Thanks!
Comment #19
xjm