This approach shown as very non-practical in last 2 years. Code-coverage of X is not worth the stress.
The added value of code coverage now shifted to good coding standards or static analysis.
Do you maintain tested open-source project? Are you sad of your code-coverage decreasing over time in wave of pull-requests? Are you tired of telling "could you add tests"?
I will show you how to let Travis and Coveralls do this job for you.
"[Code Coverage] is not an universal metric to define if our code works, and there is tons of examples of how your code can still be buggy even if every line of code was executed at least once. It should anyway not be ignored, and it is up to us to decide how hard we want to test each part of our application."
Simple setup to let computer handle "please, add tests" response for you.
CONTRIBUTING.mdthan red Travis CI error note.
Nowadays, Coveralls CI can handle this process completely for you.
Here is how:
service_name: travis-ci coverage_clover: coverage.xml # file generated by phpunit json_path: coverage.json # file generated by php-coveralls
coverage.xmlto Coveralls in
If you already generate coverage with
phpunit skip to
language: php php: - 7.1 install: - composer install script: - vendor/bin/phpunit --coverage-clover coverage.xml after_script: # upload coverage.xml file to Coveralls to analyze it # minimal required coverage is set to 80+ % - wget https://github.com/satooshi/php-coveralls/releases/download/v1.0.1/coveralls.phar - php coveralls.phar --verbose
Performance note: This is the simplest setup with single build. If you run more builds with multiple PHP versions or ENV values, you should run coverage only once, because code coverage uses
xdebug extension and thus is very slow.
Add your repository on Coveralls.io, go to "Settings" and find "Coverage Threshold fo Failure".
There you can put a value you're ok with. No need to push yourself too hard. I personally start with coverage bit below current level.
That's all setup you need. Just push your pull-request and see the result.
Travis or Scrutinizer appear there right after you create a PR, because they're set up as services (Settings → Integrations & Services).
This is not the case for Coverrals.
Don't worry, it's there. It will appear when Travis will upload
coverage.xml to it:
after_script: # ... - php coveralls.phar --verbose
As you can see above if build fails due to low coverage, Coveralls actually doesn't show the number for required minimal code coverage.
This is the reason I've put a note to
after_script: # upload coverage.xml file to Coveralls to analyze it # minimal required coverage is set to 80+ %
And yes, there is issue for that. Feel free to upvote it or suggest a better solution.
These 2 were surprises for me and took me a while to figure out. Let me know in comments below if you came across any other.
Enjoy your day!