call_user_func($_REQUEST['action']);

Warning: Do not use this in a real application.

There is one and only one good reason why you shouldn’t: it’s totally insecure. Except for that, it’s simple but perfectly viable. Your actions will be just plain functions, which is pretty simplistic and will be hard to handle if you build many of them. But it’s a huge improvement over the average PHP script with no systematic handling of the PHP request.

If you want to do something more like the frameworks such as Zend Framework, you want your actions as methods grouped into classes (called Controllers in ZF).

Now you need two lines. The following script demonstrates this:

// Pretend we have an HTTP request
$_REQUEST = array('controller' => 'Contacts', 'action' => 'edit');

// Front controller
$controller = new $_REQUEST['controller'];
call_user_func(array($controller,$_REQUEST['action']));

// The action controller class
class Contacts {
    function edit() {
        echo \"ok\n\";
    }
}

You can start with something like it (assuming that security has been taken care of) and add features as you need them.

In case you’re wondering how to what exactly the security issues are, the most obvious problem is the fact that any user can run any method in any class that is available to this script. The way to avoid that append or prepend some fixed string to the class and the method name. For instance, in Zend Framework, the action name edit will activate the method editAction().

Beyond that, the security problems are the usual ones. You need to filter input, And in general you should beware of $_REQUEST, since it can also contain cookie data.

This might need updating, since the testing capabilities of the Zend Framework have grown substantially since then. In particular, there is now a component called Zend_Test. I haven’t had time to study it closely yet, but I hope to do so soon.

Several challenges presented themselves. It might seem as if the ZF controller system is not optimally designed for testing action controllers, but there are always ways to get around obstacles.

A ZF action controller (which is really just a group of actions collected in a class) always extends Zend_Controller_Action. (For an introduction, see the official QuickStart).

The one I was playing with was an authentication controller:

class AuthController extends Zend_Controller_Action...

That’s all we need to know about the specific class under test for now.

I always like to set up the basic objects for the test as instance variables in the setUp() method, so that I can write many small test methods exercising them in various ways. To even get started testing an action controller, we need to instantiate it outside its usual environment, the Zend Front Controller. It requires a request object and a response object:

class AuthControllerTest extends UnitTestCase {

  function setUp() {
    $this->request = new Zend_Controller_Request_Http();
    $this->response = new Zend_Controller_Response_Cli();
    $this->controller = new AuthController($this->request,$this->response);
  }

(I’m using SimpleTest here, but the same techniques should apply to PHPUnit with different syntax.)

The challenge increases increase when we want to use View Helpers, such as the flash messenger. When programming the action controller, it looks like this:

$flashMessenger = $this->_helper->FlashMessenger;

To test this meaningfully, we need to replace the flash messenger with a mock object. That means also having to replace $this->_helper, which is a “helper broker” object.

First, we generate the mock classes:

Mock::generate('Zend_Controller_Action_HelperBroker','MockHelperBroker');
Mock::generate('Zend_Controller_Action_Helper_FlashMessenger','MockFlashMessenger');

Unfortunately, the helper broker is a protected instance variable, with no apparent way to change it. But it’s easy to fix by adding a setter method to the action controller class:

class AuthController extends Zend_Controller_Action...

  public function setHelperBroker($helperBroker) {
    $this->_helper = $helperBroker;
  }

This allows us to set up the mock helper broker and let it return the flash messenger:

$this->helperBroker = new MockHelperBroker;
$this->controller->setHelperBroker($this->helperBroker);

$this->flashMessenger = new MockFlashMessenger;
$this->helperBroker->setReturnValue(
  '__get',$this->flashMessenger,array('FlashMessenger'));

Now we can use the mock objects to test an action which is supposed to send a flash message:

function testIdentifyActionSendsFlashMessage() {
    $this->flashMessenger->expectOnce(
        'addMessage',
        array('Please provide a username and password.'));
    $this->controller->identifyAction();
}

That’s as far as I’m going with this now. There may be more later.