up vote 2 down vote favorite
2

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?

share|improve this question

2 Answers

up vote 1 down vote accepted

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.

share|improve this answer
up vote -1 down vote

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.

share|improve this answer
You still have to modify your code base. Apart from that, it's not a xdebug problem as you want to put it. – cweiske Apr 30 '11 at 11:56
@cweiske: OP specifically asked, "any other solutions?" – Ira Baxter Apr 30 '11 at 13:43
@cweiske: You don't have to modify your code base. The tool makes an instrumented copy that you run that has the exact same functionality as your original code, but also collects the test coverage data. You run the instrumented version, and then throw it away. Your original version isn't touched or modified by hand. It takes a fraction of a second to instrument each script you have, the process is automated and extremely reliable (because it is built on a compiler-like PHP front end ). – Ira Baxter Apr 30 '11 at 14:19

Your Answer

 
or
required, but never shown
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.