[PhpunitBridge][HttpKernel]Always display container deprecations in simple phpunit #29519
Conversation
|
This should be considered as a new feature IMHO. |
478240a to
7dbde2b
Compare
|
@nicolas-grekas I'm not sure I fully understand. Do you mean that KernelTestCase should catch container compile deprecation and display it (although other deprecations will be displayed by PHPUnit bridge) ? |
|
KernelTestCase could eg open that file and @trigger_error() them - or call the deprecation handler if possible? |
|
I can't use trigger_error since I would lose original line number information. But maybe I can deal with registered error handler. I'm going to try that, thank you :) |
|
status: needs work |
7dbde2b to
09feeae
Compare
|
status: needs work |
4763a3e to
9197928
Compare
f819427 to
14db14f
Compare
|
@l-vo What's the status of your PR? |
|
@fabpot there is more work than I originally thought. I recently didn't have the time to continue this PR but I didn't forget it :) I'm going back to work on it very soon :) |
|
@l-vo thanks for the feedback. |
8071a01 to
d2749e4
Compare
268e856 to
cadca3a
Compare
… the container is already built
cadca3a to
bf17514
Compare
|
status: needs review |
|
Sorry I didn't look close enough before. There is no reason why the phpunit-bridge should know anything about KernelTestCase. Let's find a proper way that would decouple things. There is already some code infrastructure that deals with serialized deprecations passed via messages. Can't we improve this to achieve what is needed here? |
|
@nicolas-grekas I'm not sure to understand. If we put the logic into KernelTestCase (without coupling with phpunit-bridge), we'll lose the logic of the Deprecation class of phpunit-bridge ? |
|
You mean: being able to differentiate direct vs indirect deprecations, right? But can't we trigger a serialized message as allowed by the bridge to fix that? |
|
@nicolas-grekas sorry if I miss something... We can trigger a serialized message, but we must determine in the bridge the message source. It's what is done here, but it's also what introduces the coupling with KernelTestCase. |
|
I'm closing because this would apparently add a lot of complexity for a case that happens to be solvable in other ways. There are other strategies to get the deprecations. It would be nice to achieve the goal here, but not at all costs. |
When the container is not built or not fresh, simple-phpunit may trigger deprecations which occured during container built. If simple-phpunit is launched again, the deprecations are not displayed since the container hasn't be built this time.
Deprecations can make tests fail. So the behavior is currently inconsistent. With the same code base, the tests may pass if the container has been built before and may fail if the container is built during the process.
The suggested fix is to retrieve container compile deprecations from a file created by Symfony. It's the file which is used to display container compile deprecations in Logger data collector.
Some deprecations are generated during cache warmup. Without cache warmup, these deprecations can be triggered from anywhere. For this reason, without cache warmup, we can't memorize them to display them on all test launches. So to keep test launches consistent, it could be a good practice to warmup the cache before.
Note: since phpunit-bridge create a new phpunit project with a phpunit-bridge dependency, the phpunit-bridge version used for the CI tests hasn't the modification of this PR. So the tests fail. Reporting the
DeprecationErrorHandlermodifications in the created phpunit project allows tests to be successful.Some very minor bugs has been detected after #29211; it could be a good think to fix the bugs treated by #31478 before merging this PR.