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?

Inspecting other people tests, I always see something like:

public function setUp()
{
    $this->testsub = new TestSubject();
}

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

public function testSomething()
{
    $this->assertSame('foo', $this->testsub->getFoo());
}

Of course, there is virtually no difference between this way and the "old" local variable way.

Signally

The difference is that you only need to set that code once, no matter how many tests there are in your test class – Humanism

@MarkBaker so... just when creating the test subject requires a lot of lines, for example? – Signally

A good example would be setting up a database table and destroying it again when finishing the test. – Sigridsigsmond

@ Gremo -- the setUp and tearDown are run for every test method in the class. So if you change variables of the object, you want a fresh object on your next test – Mesdames

I use this in real life scenarios on 30-50 test classes – Mesdames

Answer 1

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());
}

Holsinger

tearDown() is missing here, but basically you would unset anything that needed to be cleared, similar to a desctructor. – Cliftonclim

@StevenScott No, teardown() is intentionally NOT in my code, because setUp() will overwrite anything anyway. There is no need to write a teardown function that writes NULL to any private property of that test class. – Holsinger

@Holsinger True, the tearDown() is redundant as the setUp() will create a new object. However, I still tend to use the tearDown() to clear the object, so garbage collection might kick in sooner, and be more efficient on a large code base. Also, remember to clean up any code I create (even tests) is a good habit for developers. – Cliftonclim

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.

Vitellus

+1 for "Use it to make your life easier, or don't use it." setUp() is just a refactoring tool, to share common code. Only use it when it makes sense; don't force all fixture creation to go in there, as often each test needs a slightly different fixture! – Immethodical

Answer 3

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.

Aborn

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);
}

Classmate

You need to instantiate a MOCK of the cart that will return just the values you need to test the calculation in your class. Setting a real cart up might be way too complicated because of its own dependencies, and you cannot test whether the cart got called with the right parameters and methods. – Holsinger

@Holsinger I would agree that a mock cart would actually be best here. I was trying to simply illustrate a use case that would give an idea as to the utility of setUp() and tearDown() without having to introduce an even more advanced unit testing concept. Maybe I didn't pick the best example here :) – Classmate

Answer 5

in my opinion if your tests not high complex you not need teardown the after Test method function as before tests setup can do all required , but for example real situation may after each test save some records in db for that test, results, etc, or even send email or more deeper with CI/CD actions or use apis to assigns tasks for developers owner of tested function that failed for example with AI info maybe or use another related tools after specific test pass or fail to do specific action or create report. but in my opinion add this->x = 1 in setup and unset it in teardown not looks real example

Fake