I often come across legacy projects that have a very low code coverage (or none at all). Getting such a project up to a high code coverage can be very frustrating as you will have a poor code coverage for a very long time.
So instead of generating an overall code coverage report with every pull request I tend to create a so called patch coverage report that checks how much of the patch is actually covered by tests.
Having something like that in place also allows me to force contributors to include tests for their newly contributed code. Which in turn successively improves the overall code coverage up to a level where I might be able to go for that instead of the patch coverage.
But how to implement that?
That’s not as complicated as it sounds. As Sebastian Bergmann already wrote a tool for that.
phpcov requires us to
- first generate a diff against the last code-revision,
- then generate a coverage-report via
- then run
phpcovagainst those artefacts.
So it’s as complicated as
$ git diff HEAD^1 > /tmp/patch.txt $ ./tools/phpunit --coverage-php /tmp/coverage.cov $ ./tools/phpcov patch-coverage --path-prefix /path/to/project /tmp/coverage.cov /tmp/patch.txt
It will return a non-zero value when not all lines are covered and it will tell you which lines aren’t covered.
So add that to your automation to have it executed at whatever stage you like (I recommend in the CI-pipeline of your Pull-/Merge-Request and let that fail whenever the return code is non-zero)
If you want to see a way to implement that in GitHub Actions, check out this gist.