PHPUnit Code coverage analysis for code called over HTTP

7
votes

I am trying to find a reasonable approach to getting a code coverage report for code that is called from within a test via HTTP. Basically I am testing my own API the way it is supposed to be called but because of that PHPUnit/Xdebug are unaware of the execution of the code within the same codebase.

Basically what I want to achieve is already done using the PHPUnit Selenium extension but I don't run Selenium, I call the code through an OAuth2 Client which in turn uses curl.

Is it be possible to call my API with a GET-parameter that triggers a code coverage report and to have PHPUnit read that report and merge it with the other code coverage? Is there a project that already does that or do I have to resort to writing my own PHPUnit extension?

1
httpphpunitcode-coverage
Why is it that running the code doesn't trigger Xdebug collection of probe data? FWIW, there is another coverage tool that will collect code coverage data no matter how it is invoked, and has built in capability to combine coverage data collected in separate runs into an integrated view. But it isn't Xdebug based. Is that a requirement? - Ira Baxter
Well, the code is called via HTTP, as I understand it, PHPUnit asks Xdebug to create a coverage file but nothing is added to that file when code is called via HTTP as it is a different process in which Xdebug is not advised to create such a file. - akirk

1 Answers

1
votes

OP says the problem is that Xdebug-based code coverage collection, won't/can't collect coverage data because Xdebug isn't enabled in all (PHP) processes that execute the code.

There would seem to only be two ways out of this.

1) Find a way to enable Xdebug in all processes invoked. I don't know how to do this, but I would expect there to be some configuration parameter for the PHP interpreter to cause this. I also can't speak to whether separate Xdebug-based coverage reports can be merged into one. One the face of it, the raw coverage data is abstractly just a set of "this location got executed" signals, so merging should just be a set union. How these sets are collected and encoded may make this more problematic.

2) Find a coverage solution that doesn't involve Xdebug, so whether Xdebug is enabled or not is irrelevant. My company's (see bio) PHP Test Coverage Tool does not use Xdebug, so it can collect the test coverage data you want without an issue. You can download it and try it; there's a built in-example of test coverage collection triggered exactly by HTTP requests. The tool has a built-in ability to merge separate test-coverage runs into an integrated result. (I'd provide a direct link, but some SO people are virulently against this).