Closed (won't fix)
Project:
Drupal core
Version:
11.x-dev
Component:
phpunit
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
31 Oct 2020 at 21:21 UTC
Updated:
30 Mar 2024 at 10:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mondrakesymfony/phpunit-bridge 5.2.0 was released today
Comment #3
Pooja Ganjage commentedHi,
Creating a patch for this issue.
Please review the patch.
Thanks.
Comment #4
Pooja Ganjage commentedComment #6
anmolgoyal74 commentedComment #8
anmolgoyal74 commentedComment #9
mondrakeRemoving all the entries
and running the command
SIMPLETEST_DB={your_db_url} SYMFONY_DEPRECATIONS_HELPER='generateBaseline=TRUE&baselineFile=test.deprecation.json' vendor/phpunit/phpunit/phpunit -c core core/modules/action/tests/src/Kernel/Migrate/d6/MigrateActionsTest.phpyou get a
test.deprecation.jsonthat containsthat is, all the deprecation triggered that were previously silenced now get summarised in the file.
Brainstorming: what we need to do here (and it's quite a lot) is to be able to produce a file for each test run (because we cannot have a single file, run-tests.sh does parallelise the test execution in multiple processes), and consolidate the files into one with the summary at the end of the complete run. That file will be the 'entire' baseline for Drupal. Then, that baseline should be generated with a special test run on DrupalCI that would update the deprecation baseline every (?), and be included in the repo (?)
During the normal test runs, the 'baseline file' should be unpacked and re-allocated for each test run so that the single test baseline could be checked against its run results.
Comment #10
alexpottLet's get DrupalCI to generate merge this baseline files for us. And then we should have something we can commit to core as a baseline.
Comment #11
alexpottTrying a new location on DrupalCI after chatting to @mixologic
Comment #12
alexpottPhp notices... let's ignore them for now...
Comment #14
alexpottComment #15
alexpottLet's try this again...
Comment #16
alexpottAnd again...
Comment #17
alexpottOnce more into the breach...
Comment #19
alexpottAh we always have a temporary file...
Comment #20
alexpottLet there be one file.
Comment #21
alexpottLet's use the correct file mode!
Comment #22
alexpottNow let's reset drupalci.yml and get files for all the different runs.
Comment #25
mondrakeMoving to MR workflow and bumped to D10
Comment #27
mondrakeThe baseline has 1000s of entries related to the usage of legacy Symfony 3 MimeType classes, which I suppose would go away once #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support) is in.
However, this makes me think whether we should have somewhere a list of deprecation patterns to be ignored while building the baseline as well as while comparing against it, a la PHPStan. That’s probably something for upstream, though.
Also, now the baseline is split per test suite following the logic DrupalCI (unit, kernel, build, etc), so in any case we will need to manually merge it on a first run, unless an infra job will be able to do it.
Comment #28
alexpott#27 feels a bit related to #3143388: Allow projects to add to the list of skipped deprecations
Comment #29
mondrakeRerolled after commit of #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support)
Comment #30
mondrakeMR 1655 is about GENERATING the baseline
Comment #32
mondrakeMR 1660 is about USING the baseline
Comment #33
mondrakeComment #34
mondrakeAttached, the baseline that is resulting by 'merging' manually the files under
artifacts/run_tests.{test-suite}/phpunit-xml/deprecation_baseline.jsonfor each of the DrupalCI testsuite runs (build, functional, javascript, kernel, phpunit).
There are lots of deprecations thrown in the listeners like
that would trigger for each single test... another reason for an 'ignoreFile' per #27.
Comment #35
mondrakeI have filed upstream PHPUnitBridge - add a deprecation 'ignoreFile option' to allow silencing deprecation patterns
Comment #36
mondrakeIf we had #35 from upstream, then I think we would no longer need to bypass PHPUnitBridge's deprecation management, so we would not longer need a deprecation listener (or whatever it will be in PHPUnit 10). At the same time we could allow contrib to alter the ignore file, so not needing #3143388: Allow projects to add to the list of skipped deprecations either
Comment #37
mondrakeRerolled
Comment #38
mondrakeThis will become much simpler once #3272779: [Symfony 6.1] Replace deprecationListenerTrait with PHPUnitBridge ignoreFile will have been done.
Comment #40
mondrakeComment #41
mondrakeMR 2372 is built on top of #3272779: [Symfony 6.1] Replace deprecationListenerTrait with PHPUnitBridge ignoreFile, and modifies run-tests.sh script only, so that baseline consolidation from different files occurs at the end of each run-tests.sh execution. It does not interact with Symfony's internals.
Comment #43
mondrakeComment #44
mondrakeWorking on this.
Comment #45
mondrakeAfter #3272779: [Symfony 6.1] Replace deprecationListenerTrait with PHPUnitBridge ignoreFile, this is now rather simple.
MR 1660 --- USING the baseline
This is rather trivial. You have a baseline file --> just indicate it in the PHPUnitBridge configuration and you're done.
MR 2372 --- GENERATING the baseline
Just sligthly more complicated:
artifacts/run_tests.javascript/phpunit-xml/full_deprecation_baseline.jsoncore/.deprecation-baseline.json(see MR 1660 above)Comment #46
mondrakeThe automated baseline generation includes also deprecations triggered from within tests marked
@legacy, which does not make much sense.Opened issue upstream, https://github.com/symfony/symfony/issues/46710
Comment #47
mondrakePR merged upstream, let's wait for a Symfony patch release update.
Comment #48
mondrakeFor an approach when to use ignoreFile and when a baselineFile, https://drupal.slack.com/archives/C1BMUQ9U6/p1655711760320739
Let’s include that in a CR
Comment #49
mondrakeComment #50
mondrakeUpstram fixed. Now postponed on #3292730: Update to Symfony 6.1.2.
Comment #51
spokjeBlocker #3292730: Update to Symfony 6.1.2 just landed, unpostponing.
Comment #52
mondrakeComment #53
mondrakeSquashing together MR 2372 and #2664570: Move Attribute classes under Drupal\Component to see what baseline juice we get
Comment #55
mondrakeOK, now test the baseline generated by #53 (available at https://dispatcher.drupalci.org/job/drupal_patches/136993/artifact/jenki...) with MR 1660.
Comment #56
mondrakeComment #57
mondrakeWell, we need to include #2664570: Move Attribute classes under Drupal\Component too to make it meaningful.
Comment #58
mondrakeSuppress commit checks for the purpose of testing
Comment #59
mondrakeComment #60
mondrakeSo, what the experiments in #56 and #59 tell us:
a) the concept of deprecation baseline is different from the PHPStan baseline. It's more a 'watermark': while in PHPStan if you correct an issue without cleaning up the baseline you will get an error reporting that PHPStan was expecting an error that did not show up, this is not happening for this baseline. You can have less deprecations occurring in a test, and no error shown. But you can't have more than those in the baseline.
b) for the case of #2664570: Move Attribute classes under Drupal\Component, the generated baseline is huge, and on a run with the baseline applied we have more errors showing up --> probably it will be fair to add a ignore pattern in the ignoreFile in this case instead of baselining.
Back to NR since MR 1660 is practically the scope that needs to be done here based on the issue title - the baseline generation should probably be a separate issue.
Comment #61
longwaveThe changes are as minimal as can be to get the first version of this in so we can start using it.
Comment #62
andypostIt does not pass tests
Comment #63
andypostsorry, confused by files, there's MR !1660
Comment #64
catchWe need a change record here, and maybe core documentation updates:
- how do you generate the baseline
- how do you use the baseline (presumably nothing special?)
- how do you remove items from the baseline
- when should you continue to use the ignore list instead.
I think it'd be also useful even if we want to generate the baseline in a different issue to be able to see what that looks like for the current state of core, and what if anything would stay in the ignore list.
Comment #65
wim leersWhile working on #3316274-71: Stabilize FunctionalJavascript testing AJAX: add ::assertExpectedAjaxRequest(), I struggled a lot to add a new expected/ignored deprecation 😅 That's how I stumbled upon this issue.
It sounds like this is still worth doing? 🤓
Comment #66
mondrake#65 about ignoring deprecations, #3272779: [Symfony 6.1] Replace deprecationListenerTrait with PHPUnitBridge ignoreFile and https://www.drupal.org/node/3285162 could be better friends :)
Comment #67
wim leers#66: Yes, and those links are exactly what I looked at to figure out how to do #65. What I meant to say in #65 was that having examples of how to generate baselines would also implicitly provide examples for how to explicitly ignore specific deprecations 🤓
Comment #68
mondrakeRelated, #3295618: Get PHPStan baseline generation via DrupalCI. IIUC the idea is that we should not use DrupalCI to generate baselines, either there or here - rather wait for availability of an infra that could allow that more easily.
Comment #70
mondrakePHPUnit bridge will not have a PHPUnit 10 compatible version. Deprecation baseline is now available from PHPUnit itself, but that would be a different story.