Can you imagine a big project that has 100% code coverage? Me neither. It doesn’t mean that we should ignore this measurement. Today, I would like to describe my adventures with code coverage in the Financier project. There will be phpspec, Travis, coveralls.io and bit of dragons. Just kidding, dragons another day.
100% code coverage what does it mean? Well, you have tests for each class, method, and conditions (if, while, for), literally. Everything is testable and tested.
Pros and cons
Undeniably, it gives you guarantee that your code works. Any single piece won’t be broken after refactoring or adding a new feature. But it means you have more test that proper codes. If your big product supports a lot of languages, you have to test each one. Even they have that same business logic.
In my opinion, 100% code coverage is not suitable for a project that integrates many libraries, frameworks, and other architecture solutions together.
However, your project can consist of many smaller libraries which do one particular thing. There is the place where 100% code coverage is worth implementation.
Domain, Architecture, App
The Financier is divided into three pieces, and I’ve assumed only one must have 100% code coverage. Guess, which one.
App – integration with frameworks, takes request and returns response.
Architecture – integration Domain with external libraries or resources like Doctrine, Swiftmailer, MySQL and so on.
Domain – the most important part, it contains only business logic and interfaces for Architecture.
Congrats, you knew it.
Domain has the biggest responsibility, and it determines that must be tested well. In this situation, 100% code coverage is the just duty.
As you know, from one of mine previously notes, I use phpspec there. If you want to know how to install and use it, you will check my post about Bowling Game Kata. There, I’ve explained everything.
To measure code coverage with
phpspec, you have to install plugin and
xdebug. I’ve chosen
phpdbg. The method of running has convinced me. When you install
xdebug, you have to use it still what makes you application slower.
phpdbg is executed from a command line as separate applications so that you can use it on demand. In my case, it’s only for measuring code coverage.
phpdbq on macOS by brew.
Honestly, I had problems with installing it. I couldn’t find any working instruction how to do that. I show you how I did that. I assume you have
php installed on your mac. Remove it.
brew remove php71
When you do that, you install it again, but this time with the flag
--with-phpdbg, so whole command looks like:
brew install php71 --with-phpdbg
Done! You have
phpdbg on your mac.
Do you have Composer installed?
You can go forward if you already have Composer, if you are interested in using Composer through Docker that is possible as well.
Install plugin to code coverage
As you know, you have to use
composer. It’s standard in PHP world. So.
composer require --dev leanphp/phpspec-code-coverage
The second step, create
phpspec.yml file which contains:
format: [clover, html]
The third step, create the
build directory (and add it to
The plugin with that configuration generates two outputs. One well-look html report and xml report in common
clover standard, which you can send to tools like coveralls.io.
If you are ready, you can just run
phpdbg -qrr ./vendor/bin/phpspec run
When it finishes, look at you
build directory. There you find reports.
Travis and coveralls.io
Each software developer likes gadgets. Let’s integrate our project with travis and coveralls.io. Each build should generate counting code coverage and send a result to coveralls.io.
First, install library from coveralls.io
composer require --dev satooshi/php-coveralls
.coveralls.io file and add there
Last step, make your
.travis.yml similar to:
- composer install --dev
- phpenv config-rm xdebug.ini
- phpdbg -qrr ./vendor/bin/phpspec run
- ./vendor/bin/coveralls -x build/clover.xml
It’s everything. Commit something and be happy with your data on coveralls.io