100% Code Coverage with phpspec

100% Code Coverage

CODE COVERAGE

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.

phpspec

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 phpdbg or 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.

Install 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:

extensions:
  LeanPHP\PhpSpec\CodeCoverage\CodeCoverageExtension:
    format: [clover, html]
    output:
      clover: build/clover.xml
      html: build/coverage


The third step, create the build directory (and add it to .gitignore).

mkdir build


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


Then, create .coveralls.io file and add there

json_path: build/coveralls-upload.json


Last step, make your .travis.yml similar to:

language: php
php:
  - '7.1'
  - nightly
install:
  - composer install --dev
before_script:
  - phpenv config-rm xdebug.ini
script:
  - 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

Marcin Pilsniak

Author: Marcin Pilsniak

I have been using PHP for 13 years. Furthermore, for the last 4 years I have been using AWS in my everyday work. I’m certified AWS Architect, Developer and SysOps.