As noted in the Login example, all MVC test cases should extend Zend_Test_PHPUnit_ControllerTestCase. This class in turn extends PHPUnit_Framework_TestCase, and gives you all the structure and assertions you'd expect from PHPUnit -- as well as some scaffolding and assertions specific to Zend Framework's MVC implementation. In order to test your MVC application, you will need to bootstrap it. There are several ways to do this, all of which hinge on the public $bootstrap property. First, and probably most straight-forward, simply create a Zend_Application instance as you would in your index.php, and assign it to the $bootstrap property. Typically, you will do this in your setUp() method; you will need to call parent::setUp() when done: bootstrap = new Zend_Application( 'testing', APPLICATION_PATH . '/configs/application.ini' ); parent::setUp(); } } ]]> Second, you can set this property to point to a file. If you do this, the file should not dispatch the front controller, but merely setup the front controller and any application specific needs. Third, you can provide a PHP callback to execute in order to bootstrap your application. This method is seen in the Login example. If the callback is a function or static method, this could be set at the class level: In cases where an object instance is necessary, we recommend performing this in your setUp() method: bootstrap = array($bootstrap, 'start'); parent::setUp(); } } ]]> Note the call to parent::setUp(); this is necessary, as the setUp() method of Zend_Test_PHPUnit_ControllerTestCase will perform the remainder of the bootstrapping process (which includes calling the callback). During normal operation, the setUp() method will bootstrap the application. This process first will include cleaning up the environment to a clean request state, resetting any plugins and helpers, resetting the front controller instance, and creating new request and response objects. Once this is done, it will then either include() the file specified in $bootstrap, or call the callback specified. Bootstrapping should be as close as possible to how the application will be bootstrapped. However, there are several caveats: Do not provide alternate implementations of the Request and Response objects; they will not be used. Zend_Test_PHPUnit_ControllerTestCase uses custom request and response objects, Zend_Controller_Request_HttpTestCase and Zend_Controller_Response_HttpTestCase, respectively. These objects provide methods for setting up the request environment in targeted ways, and pulling response artifacts in specific ways. Do not expect to test server specifics. In other words, the tests are not a guarantee that the code will run on a specific server configuration, but merely that the application should run as expected should the router be able to route the given request. To this end, do not set server-specific headers in the request object. Once the application is bootstrapped, you can then start creating your tests.