PHPUnit/Xdebug Code Coverage for Codeigniter API Calls

Question

We are using Codeigniter and have 2 options to call our API controllers:

1. we can use a client that calls the controller's url through Curl,
2. we can use a client that calls the controller from the command line.

This is perfectly fine for the functionality of our site. However, when I run PHPUnit, the coverage reports for the Controllers are blank while the coverage reports for all Models are correct.

In tracing how xdebug creates the reports, it appears that using the Curl-based client or the CLI client are called outside of the scope of the test function, so xdebug_get_code_coverage() does not track the controller code that is executed.

Is it possible to configure xdebug to recognize code coverage in this scenario? Is it possible to call Codeigniter controllers within the scope of the PHPUnit test function? Any other possible solutions?

Answer 1

Yes, that's easily possible. See http://www.phpunit.de/manual/current/en/selenium.html for more information about it

Basically you put some special files in your web root:

PHPUnit_Extensions_SeleniumTestCase can collect code coverage information for tests run through Selenium: Copy PHPUnit/Extensions/SeleniumTestCase/phpunit_coverage.php into your webserver's document root directory. In your webserver's php.ini configuration file, configure PHPUnit/Extensions/SeleniumTestCase/prepend.php and PHPUnit/Extensions/SeleniumTestCase/append.php as the auto_prepend_file and auto_append_file, respectively. In your test case class that extends PHPUnit_Extensions_SeleniumTestCase, use protected $coverageScriptUrl = 'http://host/phpunit_coverage.php'; to configure the URL for the phpunit_coverage.php script.

When running a URL with the GET parameter PHPUNIT_SELENIUM_TEST_ID, the coverage information gets tracked and PHPUnit can collect it by requesting the coverageScriptUrl.

Answer 2

An alternative: see our SD PHP Test Coverage tool.

It doesn't use xdebug to collect coverage data, so it won't have xdebug's specific problems. It instruments a script to collect test coverage data; once instrumented, no matter how the script is executed, you will get test coverage data. (The instrumentation is temporary; you throw the instrumented code away once you have the test coverage data collected, so it doesn't affect your production code base). This approach does require you to explicitly list all PHP scripts for which you want coverage data; you can ignore some if you want. Usually it isn't worth the bother; most of the users simply list all PHP scripts.