8% of the files having zero test coverage are incorrectly listed.

I want to add additional rules that are correct but cast the widest net......

Removing files that match the wildcard FormTest*.php only grabs a small group of files.

better would be '*/tests/*' but there is no way in phpunit to do this....

So I have manually added every '*/test/*' in core today, this creates a maintenance headache.

But when I do this the number of files with zero coverage drops from 2182 to 2004 files.

So 8% of the files were being incorrectly listed.

I'm confused that * doesn't work, given that it works for testsuites.

Thanks @dawehner

Yeah I am confused by that ... also

I want to ditch the patch - it is unmaintainable and find out why * does not work.

I think the only way to make progress is hard.

By way of explanation I am have been having trouble,.. over the last 4 months

using

/vendor/bin/phpunit --coverage-html ~/d8CodeCoverage/

it has not been that stable or at least there are conflict with contrib modules.

For example I found out today that https://www.drupal.org/project/image_raw_formatter has a reference to an acient version of phpunit (3.7 )
in its composer.json which was causing conflicts until I dumped it.

The solution is to put the work into get D8 working on a modern version of phpunit and then tickle many active contrib project to do the same.

On a modern version of phpunit the bug might have been solved by now, or least we will not get laughed at when we ask for support

For me D8 and my contrib modules settle on phpunit 4.8.24 which according to https://phpunit.de/ is the old stable release ( supported until Feb 2017 )
I would like to shoot for the current stable release phpunit 5.3

Anyway I need to look at this some more ... but I am posting earlier because I want to hear other opinions

T

Yes it is still a problem

Just to keep track from #4

For me my D8 and my contrib modules settle on phpunit 4.8.24 which according to https://phpunit.de/ is the old stable release ( supported until Feb 2017 )
I would like to shoot for the current stable release phpunit 5.3

When I looked today, six months or so later - my dev site has advanced to phpunit 4.8.27 - so in semantic versioning terms - "up by a few patch versions"

On a modern version of phpunit the bug might have been solved by now, or least we will not get laughed at when we ask for support

I no longer think the wildcard support is going to change anytime soon :) - but February is that much closer so maybe a side issue is needed to upgrade phpunit to at version that will be supported beyond Feb.

Every time I google for something along the lines of "phpunit exclude wildcards" I see stack overflow issues grumbling about this.

the solution is always use @group tags to filter out what you don't want

here is an example from Oct 2016

http://stackoverflow.com/questions/40040243/phpunit-exclude-tests-from-e...

I cannot see a way forward on this issue.... but hope springs external

borisson_ ++ that is a really good improvement...it has brightened my day.

When I look at the test results ... it is warning we have an additional coding standard error.

unused "use" statement.

cut cut snip snip.. it is trivial to fix.

TLDR;

apropos o' nothing .. phpunit version watch.. yep as you say with php 7.2.x we are now getting warnings prompting us to run

composer run drupal-phpunit-upgrade

which today given, for myself at least. PHPUnit 6.5.8.. yay that is an improvement.

Ah cool, My comment from #1 that there is no exclude pattern was from 2015

Thanks @dawehner .. that is useful information.

It would be a pitty to axe @borisson_'s test code...

But if that works then the solution would be ...this one liner

That would catch all *Test.php *TestBase.php *TestTrait.php all well as all test submodules.

I will test a machine run overnight and report back if it works.

Ah the pattern should be

*Tests*

also a counter example of things showing up that don't fit the pattern.

Drupal\simpletest\WebTestBase

So I am currently testing

<exclude-pattern>*/Tests/*</exclude-pattern>
<exclude-pattern>*/simpletest/*</exclude-pattern>

From #17

it looks like you can specify a pattern, which I think we should do.

I am going to have to go back to the drawing board ... filtering just does not have the effect that the documentation details

Here is a screen shot from the dashboard

It does show that ArchiveTar and DisplayPluginBase are our biggest "Project Risks"

but lots of things are obscured by test files showing up unexpectedly.

*/Tests/*

and

*/simpleTest*

Just a little housekeeping

there is a follow up issue.