This is a followup to
https://www.drupal.org/project/drupal/issues/2974911#comment-12680705
One minor issue I noticed: I was seeing code coverage results for the src/Tests directory
What this highlights is that this issue was not 100% successful
#2478115: 8% of the files having zero test coverage are incorrectly listed.
The long and the short of this issue is that is a more comprehensive exclusion pattern is needed.
In addition to a case sensitivity issue, classes of this pattern are also incorrectly showing up in the test results.
./modules/simpletest/src/WebTestBase.php
<!-- Exclude all test modules, tests etc -->
<exclude-pattern>*/tests/*</exclude-pattern>
<exclude-pattern>*/Tests/*</exclude-pattern>
Plus patterns for any obvious test classes and traits.
Comment | File | Size | Author |
---|---|---|---|
#10 | 3062122-10.patch | 1005 bytes | martin107 |
Comments
Comment #2
martin107 CreditAttribution: martin107 as a volunteer commentedpatch
Comment #3
LendudeThe IS says excluding simpletest dir, so this has a trailing 's' too much.
I also think that we shouldn't exclude the simpletest dir as a whole since it also contains non-test code like the testing UI, which should be part of a coverage report.
Comment #4
martin107 CreditAttribution: martin107 as a volunteer commentedOk looking at a sample of the failing tests
ResourceTestBase
FieldKerenelTest
ResourceResponseTestTrait
This is a better response
Comment #5
Lendude@martin107 yeah that makes sense, updated the IS a bit to reflect the proposed change
Comment #6
mondrakeexclude-pattern
is probably old style. It's not documented in PHPUnit 6 (see https://phpunit.de/manual/6.5/en/appendixes.configuration.html), and actually throws a warning in PHPUnit 7 (see #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5).Whitelisting Files for Code Coverage
The element and its children can be used to configure the whitelist for the code coverage reporting.
Comment #7
martin107 CreditAttribution: martin107 as a volunteer commentedmondrake++
Thank you for the information -- about Phpunit7
It is great to have many eyes look things over.
I will sort this out.
Comment #8
martin107 CreditAttribution: martin107 as a volunteer commentedFor the record I did the last round of code coverage on
./vendor/bin/phpunit --version
PHPUnit 6.5.14 by Sebastian Bergmann and contributors.
When I try this in my phpunit.xml ( see below )
I still see these inappropriate items ls in the Project risk section
Drupal\Tests\jsonapi\Functional\ResourceTestBase
Drupal\block\Tests\BlockTestBase
Drupal\content_translation\Tests\ContentTranslationTestBase
ResourceResponseTestTrait
back in Nov 2016
https://www.drupal.org/project/drupal/issues/2478115#comment-11758884
I did a little stackoverflow search and noted all the problems people were having to get wildcards working.
The response was always "use a modern phpunit version".
I was hoping our push to use updated versions via composer would resolve these issues. Back then I settled on the exclude-pattern -- That is not longer appropriate.
It takes a long time to iterate - I am thinking maybe I should wait until this patch is in
#2974911: Allow run-tests.sh to generate coverage reports
which will make things faster.
Maybe others will read the documentation differently and see that I am making a stupid mistake
Comment #9
Mile23I was successful with this:
This still has some problems for custom/contrib because we can't use a pattern. It also still excludes everything under sites, which could include other custom/contrib extensions.
Also the documentation is kind of not good when it comes to telling you how wildcard expansions might or might not work. https://phpunit.de/manual/6.5/en/appendixes.configuration.html
Comment #10
martin107 CreditAttribution: martin107 as a volunteer commentedThanks Mile23, that the second time in a week you have solved my problems.
I think your solution is good and we should stop there.
That the beauty of open source .. I don't like the wildcard support of phpunit -- submit a patch.
Composer provides "installer paths" so the position of contrib modules needs to be assessed on a install by install basis.
My motivation is to reduce the cognitive load of the next developer ... when assessing project risks.
People with more specific needs, and I am one, can just follow your lead and add the modules they care about.
Mile23++
Comment #11
jibranIf this is blocking a normal task #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5 then this is a normal task.
Comment #13
martin107 CreditAttribution: martin107 as a volunteer commentedThe code changes are ignored unless xdebug or similar is enabled.
Comment #15
mondrake#14 seems a random failure too
Comment #16
catchCommitted 1dfafff and pushed to 8.8.x. Thanks!
Comment #19
effulgentsia CreditAttribution: effulgentsia at Acquia commentedI posted a follow-up to take into account submodules in #3208428: PHPUnit doesn't filter out test files within submodules for code coverage reports.