News Archive
PhpRiot Newsletter
Your Email Address:

More information

Debugging Zend_Test

Note: This article was originally published at Planet PHP on 20 September 2010.
Planet PHP

Sometimes, I have to debug unit tests and usually this is a situation I'm trying to avoid.

If I have to spend too much time debugging a test it's usually a bad test. Which usually means that it's too complex. However, with Zend_Test_PHPUnit_ControllerTestCase, it's often not the actual test, but the framework. This is not just tedious for myself, it's also not the most supportive fact when I ask my developers to write tests.

An example

The unit test fails with something like:

Failed asserting last module used was "default".

Translated, this means the following:

  • The obvious: an error occurred.
  • The error was caught by our ErrorController.
  • Things I need to find out:
    • What error actually occurred?
    • Why did it occur?
    • Where did the error occur?

The last three questions are especially tricky and drive me nuts on a regular basis because a unit test should never withhold these things from you. After all, we use these tests to catch bugs to begin with. Why make it harder for the developer fix them?

In my example an error occurred, but debugging Zend_Test also kicks in when things supposedly go according to plan. Follow me to the real life example.

Real life example

I have an Api_IndexController where requests to my API are validated in its preDispatch().

Whenever a request is not validated, I will issue "HTTP/1.1 401 Unauthorized". For the sake of this example, this is exactly what happens.

class ApiController extends Zend_Controller_Action { protected $authorized = false; public function preDispatch() { // authorize the request // ... } public function profileAction() { if ($this-authorized === false) { $this-getResponse()-setRawHeader('HTTP/1.1 401 Unauthorized'); } // ... } }

Here's the relevant test case:

class Api_IndexControllerTest ... public function testUnAuthorizedHeader() { $this-dispatch('/api/profile'); // unauthorized $this-assertResponseCode(401); } }

The result:

1) Api_IndexControllerTest::testUnAuthorizedHeader Failed asserting response code "401" /project/library/Zend/Test/PHPUnit/Constraint/ResponseHeader.php:230 /project/library/Zend/Test/PHPUnit/ControllerTestCase.php:773 /project/tests/controllers/api/IndexControllerTest.php:58

Not very useful, eh?


Before you step through your application with print, echo and an occasional var_dump, here's a much better way of see what went wrong.

I'm using a custom Listener for PHPUnit, which works sort of like an observer. This allows me to see where I made a mistake without hacking around in Zend_Test.

Here is how it works

Discover my PEAR channel:

sudo pear channel-discover


till@till-laptop:~/ sudo pear install downloading Lagged_Test_PHPUnit_ControllerTestCase_Listener-0.1.0.tgz ... Starting to download Lagged_Test_PHPUnit_ControllerTestCase_Listener-0.1.0.tgz (2,493 bytes) ....done: 2,493 bytes install ok: channel://

If you happen to not like PEAR (What's wrong with you? ;-)), the code is also on github.


This is my phpunit.xml:



Whenever I run my test suite and a test fails, it will add something like this to the output of PHPUnit:

PHPUnit 3.4.15 by Sebastian Bergmann. ..Test 'testUnAuthorizedHeader' failed. RESPONSE Status Code: 200Headers: Cache-Control - public, max-age=120 (replace: 1) Content-Type - application/json (replace: 1) X-Ohai - WADDAP (replace: false)Body:{"status":"error","msg":"Not authorized"}F..Time: 5 seconds, Memory: 20.50MbThere was 1 failure: 1) Api_IndexControllerTest::testUnAuthorizedHeader Failed asserting response code "401" /project/library/Zend/Test/PHPUnit/Constraint/ResponseHeader.php:230 /project/library/Zend/Test/PHPUnit/ControllerTestCa

Truncated by Planet PHP, read more at the original (another 1019 bytes)