Lately, I've been experimenting with ways to improve my Test-Driven Development (TDD) skills. One of the most impactful tools I've come across is PCOV, a lightweight and fast code coverage driver. By using PCOV's coverage reports, I've gained valuable insights into how effectively my tests are covering my code.

For those unfamiliar, PCOV seamlessly integrates into your test suite, tracking which parts of your code are being executed during tests. The result? A detailed code coverage report—a tool that reveals which areas of your application are well-tested and which might need more attention. But before diving deeper, let's take a step back and understand what a code coverage report really is and why it's a game-changer for developers.

Code coverage report

Code coverage report is a report that typically would collect certain metrics when our test suite is executed and it will be able to tell us how much code of our application is being covered using the tests that we have written.

A typical code coverage report will look something like this:

Code coverage report with PCOV

You can see that this report tells us which part of our codebase is covered through tests. And if we want, we can drill down to each class and their methods to understand how much code is covered and literally understand which block of code gets executed and whether there are some blocks which are not getting captured.

Just as an example, if I initially have a class with no test for it, the coverage code would look something like this:

No code coverage for a class

Right now, there are no tests, and hence you will see that everything is highlighted in red and on top, it shows that the total coverage percentage is zero.

Now to understand the advantage of code coverage, let's write a few tests first

Writing PEST test for code coverage

In here, intentionally I have missed out a case for the EV car. And now if we see the result of our code coverage, we will understand how that case is getting missed.

Code coverage showing lack of coverage

In here, if you see I have about 83.33% coverage and most important thing is line 10 which needs to return 2 is in red. This indicates that all the tests that executed never reached this particular case and hence our coverage report is telling us that we have untested code.

Now obviously it's a very simplified example shown to make you understand the concept. Image if you have classes handling a lot of complex business logic which you need to test. In such situations, if you have a tool which can tell you about the coverage based on your code, it's a big advantage.

So, now that we understand why we need it and what are the benefits of using a code coverage tool like PCOV, let's understand how it works. Because when we understand the working on PCOV, we will understand that it's not a magic recipe which will ensure that there are no bugs if we have 100% coverage.

How PCOV works?

So when you are talking about code coverage, we need to understand that PCOV is right now one of the most performant way. The reason is that it hooks directly into the PHP interpreter at low level and collects the coverage information. Coverage data is collected and stored in memory and then uses tools like PHPUnit to generate the coverage report.

The reason is very simple, PCOV is developer for a very specific reason. PCOV is only concerned with the code coverage. It goes line by line for the analysis. It will literally have a map of all the functions in your code and as the tests go through those lines of code, it marks them as covered.

How PCOV is different from Xdebug?

Now, when you go deep into this space you will also hear about Xdebug (if you have not already heard about it). And, you will also hear that Xdebug is slower than PCOV. Now, here I want you to understand that the comparison between Xdebug and PCOV should not be done.

Xdebug on the other hand has a much wider use case. It does code coverage, profiling data, debugging information etc. And, to be honest Xdebug understands the path and can help in performance bottlenecks, or memory leaks which won't be possible with PCOV.

Best use cases of PCOV

Because of it's speed, PCOV is a preffered tool when you want to get code coverage report only. Although it may not have the deep level understanding how Xdebug would, it's does a great job.

And because of this, you will see a lot of places PCOV being used with CI/CD pipelines as well to generate code coverage report. In my company Focalworks we also integrate it with Sonarqube that we have self hosted so that Sonar is aware of our code quality and we can configure rules where it can fail pipelines if the overall test coverage drops beyond a certain threshold. Below is a screenshot showing how Sonar knows about the code coverage and helps us create the gate.

Conclusion

With the use of PCOV, I can now get a much better idea about the code coverage that I have on my project. It does allow as a developer to understand your tests better and also realise what scenarios will be required so that you are able to back your code using tests.

It also fits very well into the CI/CD pipelines and hence we can do additional stuff like add rules for code coverage and even integrate it with Sonarqube.