One of the most time-consuming parts of writing tests is writing the code 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.
In Example 4.1, the fixture
was simply the array that is stored in the
variable. Most of the time, though, the fixture will be more complex
than a simple array, and the amount of code needed to set it up will
grow accordingly. The actual content of the test gets lost in the noise
of setting up the fixture. This problem gets even worse when you write
several tests with similar fixtures. Without some help from the testing
framework, we would have to duplicate the code that sets up the fixture
for each test we write.
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.
is where you clean up the objects against which you tested.
We can now refactor Example 4.1 and
setUp() to eliminate the code duplication that
we had before. First we declare the instance variable,
$fixture, that we are going to use instead of a
method-local variable. Then we put the creation of the
array fixture into the
method. Finally, we remove the redundant code from the test methods and
use the newly introduced instance variable,
$this->fixture, instead of the method-local variable
$fixture with the
Example 7.1: Using setUp() to create the Array fixture
class ArrayTest extends PHPUnit_Framework_TestCase
protected function setUp()
// Create the Array fixture.
$this->fixture = array();
public function testNewArrayIsEmpty()
// Assert that the size of the Array fixture is 0.
public function testArrayContainsAnElement()
// Add an element to the Array fixture.
$this->fixture = 'Element';
// Assert that the size of the Array fixture is 1.
tearDown() will be
called once for each test method run. While it might seem frugal to
only run these methods once for all the test methods in a test-case
class, doing so would make it hard to write tests that are completely
independent of each other.
Not only are
run once for each test method, but the test methods are run on fresh
instances of the test-case class (see Chapter 19).
tearDown() are nicely
symmetrical in theory but not in practice. In practice, you only need
tearDown() if you have allocated
external resources like files or sockets in
setUp() just creates plain PHP objects, you
can generally ignore
tearDown(). However, if you
create many objects in your
setUp(), you might want
unset() the variables pointing to those objects
tearDown() so they can be garbage collected.
The garbage collection of test case objects is not predictable.
What happens when you have two tests with slightly different setups? There are two possibilities:
setUp() code differs only slightly, move
the code that differs from the
setUp() code to
the test method.
If you really have a different
setUp(), you need
a different test-case class. Name the class after the difference in
PHPUnit does not provide convenient support for suite-level setup. There are few good reasons to share fixtures between tests, but in most cases the need to share a fixture between tests stems from an unresolved design problem.
A good example of a fixture that makes sense to share across several
tests is a database connection: you log into the database once and reuse
the database connection instead of creating a new connection for each
test. This makes your tests run faster. To do this, write your database
tests in a test-case class named
wrap the test suite in a
TestSetup decorator object
setUp() to open the database
tearDown() to close the connection, as
You can run the tests from
DatabaseTests through the
DatabaseTestSetup decorator by invoking, for instance,
PHPUnit's command-line test runner with
Example 7.2: Writing a suite-level setup decorator
class DatabaseTestSetup extends PHPUnit_Extensions_TestSetup
protected $connection = NULL;
protected function setUp()
$this->connection = new PDO(
protected function tearDown()
$this->connection = NULL;
public static function suite()
return new DatabaseTestSetup(
It cannot be emphasized enough that sharing fixtures between tests reduces the value of the tests. The underlying design problem is that objects are not loosely coupled. You will achieve better results solving the underlying design problem and then writing tests using stubs (see Chapter 10), than by creating dependencies between tests at runtime and ignoring the opportunity to improve your design.