In this post I'll demonstrate a unit test technique for testing Zend Framework Action Controllers using Mock Objects. Unit testing controllers independently has a number of advantages: you can develop controllers test-first (TDD), develop and test all of your controller code before developing any of the view scripts and helps you quickly identify problems in the controller, rather than problems in one of the combination of Model, View and Controller.

He sets up a sample user controller and a test case to go along with it. Drop in a test for the user controller class that uses a "getMock" method to define a mock controller object for the "render" method. He also points out a few issues with this sort of testing in the Zend Framework - the return value of the Zend_Test_PHPUnit_ControllerTestCase, issues throwing exceptions with the Front Controller and a problem with the dispatcher's storage of the Action Controller.

I ran into problems very quickly - when I tried to write the first unit test for the first action in fact! PHPUnit was just dying when I asked it to dispatch() any URL which didn't return HTML, it wasn't even giving its usual output. What was actually happening was I was making use of Zend_Controller_Action_Helper_Json, my service returns JSON and this action helper takes input, transforms it into JSON, sets the content-type correctly and tells ZF not to look for a view since we don't need one. I thought this was pretty neat.

As it turns out, there was an exit being called in the Zend_Controller_Action_Helper_Json component that was causing the request to stop at a certain point. The solution? Chaning the value of the supressExit class variable to stop the behavior.

Proponents of Object Oriented Programming feel the paradigm yields code that is better organized, easier to understand and maintain, and reusable. [...] If objects truly model the way people think of things in the real world, then why do people have a hard time understanding and working in OOP? I suspect the problem might be the focus on objects instead of actions.

He goes on to explain that, in his opinion, the functionality would be more understandable if it focused on the actions from the user's point of view rather than what the object itself can do.

The way some OOP languages (like Java and C#) force objects on the programmer borders on the absurd. [...] Sadly though, that decision isn't left to the programmer who has been tasked with developing and maintaining a system.

In Zend Framework based applications, error handling is typically done using the error controller, but there are different ways to send the execution to it - some better than others. Let's look at some ways to trigger the error controller and how to have it handle different error conditions.

He walks through the steps to create the Error controller, change the front controller to use it and add in a few different kinds of actions to handle the various error types that might come up (like "page not found" or "not authorized"). Errors can then be forwarded to each of the actions by the resource the visitor errored from. Of course, he also mentions that exceptions can do something even better - handle the error without all of that messy forwarding around. (There's an example of that version too).

Although I'm not posting here much at the moment, I am answering questions about my Zend Framework book in Manning's Author Online forums. [...] Also, I have started posting up the errata that we have found on the book's website. If something doesn't make sense, check there first!

Those forums are quite a busy place with topics about specific parts of chapters to more general Zend Framework questions.

In this specific case, the first of these files was defined as a basic controller, and was provided with the ability to paginate the aforementioned blog entries via the corresponding pagination class included with CodeIgniter. However, in its current incarnation, the blog application is pretty limited. It doesn't let users post comments on each blog entry. Thus, in the next few lines I'll be improving the signature of the controller class to address this important issue.

The review the code from before (showing the pagination of the blog entries) and add onto it a new comments method and how to create a new view to show the messages visitors to the site have submitted.

The core of your average web framework is a Front Controller. Front Controllers are commonly considered complex and esoteric. That's a myth. I sometimes brag that I can construct a Front Controller in 15 minutes. Actually, it's doesn't take quite that long. In PHP, a Front Controller can be simplified to just one line of code.

This one line of code, while a very dangerous thing to actually use in an application, illustrates what a front controller does to forward out the request to the rest of the framework. He revises it with a Zend Framework-ish example that splits the request out into a controller/action method.

Hooks are a feature of action helpers that allow you to automatically run code at certain points in the dispatch cycle. Specially, there are two hook functions available for action helpers: preDispatch and postDispatch. These allow you to ensure that some functionality is always run for each request.

He creates a simple action helper that grabs a random quote from an array and drops it into a property of the helper. By defining a preDispatch method inside of the helper, the HelperBroker knows to pull the method in an execute it immediate before the rest of the actions are executed. A calls to addHelper with the hooks defined is all it takes to glue it together with the execution.

When you have some functionality that needs to be shared across multiple controllers, one method is to use action helpers. Action helpers are very powerful and contain hooks to automatically run when you need them too, but you can ignore all that if you don't need it.

He includes how to set up the "helper broker" pointing it at your helper files and a simple helper that multiplies the input times two. This helper is then applied inside of his example action (in an IndexController, of course) and assigned to an output variable in the view. He's included a code download as an example.

This post is the second part of my introductory text on Zend Framework, Starting with Zend Framework. This time I cover the basics about controllers, actions, view scripts and view helpers. On request routing and the Front Controller I will write one (or more) big post(s), so this part won't be explained now. I will also skip explaining the models; they deserve their own post.

He goes a step further and looks at Controllers - what they are and some intro steps to you making one of your own - and the parts around them, the views, actions and view helpers.