Overhead of setUp and tearDown in unit tests

I was watching the output of my Grails unit tests and noticed that tests using the mockDomain feature of the new Testing Plugin seemed to run just slightly slower than straight up unit tests.  This makes sense, as these tests are doing some meta programming magic to add mock dynamic methods and also remove them after each test run – and that takes a little extra time. But time is the enemy of testing, and I want my tests to run as fast as possible. That way I’m not discouraged from writing them or running them on a consistent basis.

So I’ve started writing tests a little differently and have been trying to reduce the number of times setUp() and tearDown() are called within a test class.  This is probably a good practice, regardless of the unit testing mechanism you’re using. Here’s an example – I used to have really verbose test methods, like this:

testFirstNameBlankConstraint(){...}
testFirstNameNullableConstraint(){...}
testFirstNameMaxSizeConstraint(){...}
testFirstNameValid(){...}

I like this pattern because each test method tested one thing – so if the test method failed, it was pretty obvious what went wrong.

However, setUp and tearDown methods were being called for each of these test methods which added some extra time to run the test suite. In a relatively small project, the time is so negligible it doesn’t matter. But on a large project with thousands of tests, it can be a noticeable difference.

Now when I’m writing my tests, I set ‘em up more like this:

testFirstNameConstraint() {
    // some test code
    assertEquals ("blank constraint", ..., ...)
 
    // some test code
    assertEquals ("null constraint", ..., ...)
 
    // some test code
    assertEquals ("max size constraint", ..., ...)
 
    // some test code
    assertEquals ("valid", ..., ...)
}

In this example, the same testing is occurring, but I have only one test method instead of four (three less calls to setUp and tearDown). By passing a message as the first parameter to the assertions, I can still quickly determine which assertion failed, and my test suite runs more quickly.