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.
The unit test fails with something like:
Translated, this means the following:
- The obvious: an error occurred.
- The error was caught by our
- 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
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:
Not very useful, eh?
Before you step through your application with
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
Here is how it works
Discover my PEAR channel:
If you happen to not like PEAR (What’s wrong with you? ;-)), the code is also on github.
This is my
Whenever I run my test suite and a test fails, it will add something like this to the output of PHPUnit:
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
The quickfix is to do the following in my action:
That’s all. Quick, but not so dirty. If you noticed, I got away without hacking
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.