Any real word example about how setUp() and tearDown() should be used in PHPUnit?

Question

Methods setUp() and tearDown() are invoked before and after each test. But really, is there any real word example about why should I need this?

Answer 1

There is a memory leak in provided example in accepted answer. You should add tearDown:

protected function tearDown()
{
    $this->_mockedService = null;
}

PHPUnit creates new test case object for every test method call. So if there are 4 test method's - there are will be 4 objects, and 4 mockedService's will be created. And they wouldn't removed until the end of the script (entire test suite). So you need to delete all objects and unset all variables in tearDown to prevent memory leak.

Answer 2

You can instantiate a bunch of fixture objects and have them available as instance variables in each test instead of constructing them individually for each test.

You can create resources like a file handle in the setUp then make sure you close them in tearDown. If you're writing temporary files, you can make sure you delete them. If you open a database connection, you can close it (though you might want to do that elsewhere - setupBeforeClass / tearDownAfterClass which get called for every test file, not for every test case.)

It's just a before/after hook which is a groovy thing to have in general. Use it to make your life easier, or don't use it.

Answer 3

If you do every test method individually, your test code will share a lot of lines that simply create the object to be tested. This shared code can (but not SHOULD) go into the setup method.

Anything that needs to be done to create the object to be tested then also goes into the setup method, for example creating mock objects that are injected into the constructor of the tested object.

Nothing of this needs to be teared down because the next call to setup will initialize the class member variables with a new set of objects.

The only thing that needs teardown is if your test leaves something behind permanently, like files that got created, or database entries. It really isn't a very good idea to write tests that do such things, but at some point you cannot abstract anymore and have to touch stuff like the harddrive, database or the real network.

So there is a lot more setup than teardown needed, and I always delete the teardown method if there is no work to be done for this test.

Regarding mocks, I work like this:

private $_mockedService;
private $_object;
protected function setUp()
{
    $this->_mockedService = $this->getMock('My_Service_Class');
    $this->_object = new Tested_Class($this->_mockService);
}

public function testStuff()
{
    $this->_mockedService->expects($this->any())->method('foo')->will($this->returnValue('bar'));
    $this->assertEquals('barbar', $this->_object->getStuffFromServiceAndDouble());
}

Answer 4

You could use this almost anytime you would have a dependency within the class you are testing. A classic example of this might be some sort of object storing application state (a session object, a shopping cart, etc.).

Say for example I had a class that was going to calculate shipping costs on the contents of a shopping cart defined by a cart object. And let's say this shopping cart is passed into the shipping calculation class via dependency injection. To test most methods of the class you might need to actually instantiate a cart object and set it in the class in order to unit tests your various methods. You might also need to add items into the cart ass well. So you might might have a setup like this:

public function setUp()
{
    $this->cart = new cart();
    $this->cart->add_item('abc');
    $this->cart->add_item('xyz');
}

Let's also assume your test methods might actually modify the cart's items, decorating them with shipping cost information. You don;t want information from one test bleeding into the next, so you just unset the cart at the end.

public function tearDown()
    unset($this->cart);
}