It would be nice if pcov and phpunit's php-code-coverage communicated over directory filtering

[HenkPoley]

With the default setting of not setting pcov.directory, pcov will latch onto either ./src, ./lib or, ./app. Leaving the end user confused why adding extra directories in phpunit.xml doesn't do anything:

https://github.com/sebastianbergmann/php-code-coverage/issues/741

It would be nice if in some way, the directories whitelisted in phpunit.xml or --whitelist <dir> would change a pcov.directory-like filter, according to the Rule of Least Surprise.

---

For now I'll try to see if I can move CentOS and Ubuntu or Debian to write pcov.directory=. in /etc/php/7.*/mods-available/pcov.ini, but that is less optimal and takes a bit of luck to find someone who just had their breakfast and coffee and is in a good mood to apply such a change. It also doesn't 'solve' it anywhere else. Neither is it really a proper solution.

---

Hedging my bets: https://youtrack.jetbrains.com/issue/WI-52914

[fennik]

Any update on this?

We have just run across the issue in our laravel project where we have introduced a second directory src/ additional to the default app/ directory. As a result of having 2 directories, we get 0% coverage across the board.

Haven't found a workaround yet

[kubawerlos]

@fennik you can set pcov.directory to the project's root - this is how I did it: https://github.com/kubawerlos/php-cs-fixer-custom-fixers/blob/v2.4.1/.github/workflows/ci.yaml#L64

[crabmusket]

While investigating this, I came across this blog post. I'm going to see if xdebug handles this situation better. https://thephp.cc/articles/pcov-or-xdebug

EDIT: using xdebug for coverage seems to Just Work ™️ so I'm using that to solve this problem. Hope that helps future searchers who used pcov by default!