Code Coverage Reports

In this video you will learn how to generate Code Coverage Reports using Codeception.

As a disclaimer to this video, I want to highlight the fact that in the version I have used in this tutorial series (Codeception v2.0.5), generating Code Coverage is quite buggy.

Specifically, Remote Code Coverage (think Acceptance tests) is pretty much a no-go.

Local Code Coverage (think Unit and Functional tests) works, in a manner of speaking.

To make this work, you're going to need XDebug installed and working. If you don't, please check out my screencast on How to Setup XDebug with PHPStorm before continuing.

One thing to note - the way I use Code Coverage is perhaps not the industry norm.

I use Code Coverage to give a report on the specific methods I am working on - not to tell me how much of the project as a whole is covered.

The reason I do this is that aiming for 100% coverage is largely unrealistic on the projects I work on. However, being able to get a reading as to how well tested the given function or method I am working on can be invaluable, especially on nests of if's and else's, particularly in legacy codebases.

You will need to add some additional config to your codeception.yml file to get this working. Check out the Code Coverage Configuration section for the most up to date way to achieve this.

Then, to run our tests in a way that will generate the Code Coverage Report, we can use the following command (providing your following along with this tutorial series):

php vendor/codeception/codeception/codecept run unit --coverage --coverage-html --coverage-xml

This will spit out a coverage report in both HTML and XML versions.

As you'll see from the video, if we use just the basic Coverage Configuration then the output of the report is full of stuff that we likely don't particularly care about - at least, not in the context of our project.

We can get round this by setting up a Whitelist and Blacklist. This is pretty simple and there's an example on the Codeception docs, but more specific to our project, that would look something like this:

    enabled: true
      - src/*
      - app/*
      - vendor/*
      - web/*

The one I use in the video is for the Symfony 3.0 directory structure. I kinda jumped the gun on that one, and no one seems to be using it. Yet.

One thing to remember, when generating coverage, if you don't want the remnants left over on your next coverage generation, be sure to run the clean command:

php vendor/codeception/codeception/codecept clean

After that it's really all about using your Code Coverage Reports to cut the CRAP out of your code :)

Code For This Course

Get the code for this course.


# Title Duration
1 Installing Codeception in Your Symfony 2 Project 04:20
2 Bootstrapping Codeception 02:09
3 Codeception's Folder Structure 06:43
4 Generating Tests 06:28
5 How to Run Codeception Tests 02:44
6 Our First Acceptance Test 08:00
7 An Alternative Perspective on Acceptance Testing 04:33
8 Acceptance Testing Symfony Forms 08:22
9 Acceptance Testing and Javascript (Part 1 of 2) 07:31
10 Acceptance Testing and Javascript (Part 2 of 2) 08:06
11 An Introduction to Unit Testing in Codeception 04:24
12 Unit Testing a Symfony Service 11:59
13 Integration with Symfony 2 06:27
14 Databases and Unit Tests 14:21
15 Real World Unit Testing - Database Clean Up Issues 06:15
16 Fast PHP Unit Testing with SQLite Database 10:19
17 Mocking the Entity Manager 20:22
18 Codeception Selenium Setup 06:08
19 How to Setup XDebug with PHPStorm 07:36
20 Step Objects and Page Objects 09:35
21 Fizz Buzz Kata 24:43
22 Code Coverage Reports 10:30
23 Running Acceptance Tests Faster With Phantom JS 01:30
24 Mobile Browser Tests 01:18