Problem/Motivation
After #3465602: Order tests by number of public methods to optimize gitlab job times, test classes within a test job will be ordered by number of test methods descending.
Data providers mean that the number of test method runs diverges from the number of test methods, so we currently have to use @group #slow to identify most tests with data providers (at least ones with significant setup tasks) so that they run first.
Steps to reproduce
Proposed resolution
If we did some additional reflection work, we could detect the @dataProvider annotation, and add a 'bonus' to the method count, like +5 or +10 or something. Doing this would allow @group #slow to be removed from those tests which only have @group #slow due to a data provider, leaving just the ones which really are genuinely slow to run (Umami installs et al).
Additionally, if we order by type of test, this should benefit contrib test runs that run multiple types of test in the same job with concurrency (which is how the default template works) - i.e. functionl js tests first and unit tests last.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3470179
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
catchComment #4
catchSince this adds a bit of complexity, tried to tidy up the overall logic to make it more parseable at the same time.
Comment #5
catchThis keeps the four kernel test jobs at around 2 minutes each while removing @group #slow from dozens of tests.
https://git.drupalcode.org/project/drupal/-/jobs/2553451
https://git.drupalcode.org/project/drupal/-/jobs/2553452
https://git.drupalcode.org/project/drupal/-/jobs/2553453
https://git.drupalcode.org/project/drupal/-/jobs/2553454
Comment #6
smustgrave commentedWent to review but needs a rebase
Comment #7
catchRebased.
Note the weighting by test type doesn't affect core tests, but I'm hoping it will allow us to optimise contrib test run times/resource usage.
Comment #8
smustgrave commentedAppears random right?
Comment #9
smustgrave commentedBelieve test failure is random.
Comment #10
catchRebased here after a few more test optimisation issues landed and to try to get a clean pipeline. Most recent pipeline on the MR now is green and took 5m41s https://git.drupalcode.org/project/drupal/-/pipelines/274771
Comment #11
catchNo longer applied. Rebase wasn't clean but merging in 11.x was.
Last pipeline - 5m29s which is as good as HEAD gets at the moment. https://git.drupalcode.org/project/drupal/-/pipelines/287590
Comment #12
catchComment #13
longwaveCouple of nits on the MR.
Comment #15
quietone commentedUpdated the MR per longwave's review.
Comment #16
catchThe changes look good. match(TRUE) still feels like cheating to me but it is a lot more compact so I just need to get used to it. I think I can RTBC since it was just tweaks.
Comment #18
longwaveCommitted 94b717e and pushed to 11.x. Thanks!
Comment #19
longwaveAgain, maybe we want to backport this to 10.4.x? Doesn't apply cleanly to run-tests.sh unfortunately.
Comment #20
catchI was able to get a clean backport by first backporting #3465602: Order tests by number of public methods to optimize gitlab job times. Only use statements conflicted after that, so went ahead.