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
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:
coverage: enabled: true include: - src/* exclude: - 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
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 :)
If you have found this video helpful, please consider sharing. I really appreciate it.
|1||Installing Codeception in Your Symfony 2 Project||04:20|
|3||Codeception's Folder Structure||06:42|
|5||How to Run Codeception Tests||02:43|
|6||Our First Acceptance Test||08:00|
|7||An Alternative Perspective on Acceptance Testing||04:33|
|8||Acceptance Testing Symfony Forms||08:22|
|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:10|
|23||Running Acceptance Tests Faster With Phantom JS||01:30|
|24||Mobile Browser Tests||01:18|