Just for the record, I guess this is the concrete piece of code you're referring to:
class ControllerTestCase extends Zend_Test_PHPUnit_ControllerTestCase
{
public $application;
public function setUp()
{
$this->application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/config/settings.ini'
);
$this->bootstrap = array($this, 'bootstrap');
parent::setUp();
}
public function tearDown()
{
Zend_Controller_Front::getInstance()->resetInstance();
$this->resetRequest();
$this->resetResponse();
$this->request->setPost(array());
$this->request->setQuery(array());
}
public function bootstrap()
{
$this->application->bootstrap();
}
}
In unit testing, the setUp
and tearDown
methods are used to
set the world up in a known state and
then return it to its original state
when the test is complete. This known state is called the fixture of the test.
The way fixtures are handled may differ between xUnit libraries, yet the concept remains the same. See also the fixtures chapter in the PHPUnit manual:
PHPUnit supports sharing the setup
code. Before a test method is run, a
template method called setUp() is
invoked. setUp() is where you create
the objects against which you will
test. Once the test method has
finished running, whether it succeeded
or failed, another template method
called tearDown() is invoked.
tearDown() is where you clean up the
objects against which you tested.
Hence, PHPUnit takes care of executing the setUp
method before every single test method included in the test case class, while tearDown
is processed after each execution.
Having that said, the Zend Framework provides with an extra layer on top of PHPUnit for running functional tests, this is, black-boxed tests on features rather than on individual units of source code. This is achieved by extending Zend_Test_PHPUnit_ControllerTestCase so that the access to the application resources is guaranteed.
In this particular example, the application is bootstrapped before every test in the test case is executed. This makes sense if we take into account that we don't need the application resources everywhere, like for instance in raw unit tests (part of other test cases).