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:

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.

Here’s the relevant test case:

The result:

Not very useful, eh?

Debugging

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:

Install:

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

Usage

This is my phpunit.xml:

Output

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

Analyze

Analyzing the output, I realize that my status code was never set. Even though I used a setRawHeader() call to set it. Turns out setRawHeader() is not parsed so the status code in Zend_Controller_Response_Abstract is not updated.

IMHO this is also a bug and a limitation of the framework or Zend_Test.

The quickfix is to do the following in my action:

Fin

That’s all. Quick, but not so dirty. If you noticed, I got away without hacking Zend_Test or PHPUnit.

The listener pattern provides us with very powerful methods to hook into our test suite. If you see the source code it also contains methods for skipped tests, errors, test suite start and end.