Brian Button writes this post about a best practice he believes in when writing unit tests.

 

The main idea in that post is that when you use Setup and TearDown methods in your tests, you're essentially separating parts of the unit tests into 2 or three areas in the class, thus making the person reading the tests more likely to miss out on some subtleties inside the test method. In short, the test is less readable if there is a "hidden" setup  that occurs before it happens. He also notes this best practice is valid for things that are *not* resource based (such as initializing things inside the file system etc..). The final thought in that post says that you would rather have a little duplication in your tests rather than remove readability.

 

While I do believe that using Setup makes the test less readable, I do not believe that a little duplication is OK.

The problem with code duplication in your tests is that it soon (very soon) leads to unmaintainable tests.

   You're creating an object instance inside 20-50 tests in your test fixture, and now suddenly the design changes and the class constructor signature changes. Do you really think fixing 50 tests is something a developer will take the time to do? Maybe once. What about the second time this happens? and the third? And what specific point in time will this developer start thinking " Gosh darn it, these tests are more trouble than their worth, and I have a deadline to reach!" and finally let the tests keep on failing?

 

Sooner than you think.

 

I've seen this happen time and time again. With Unit tests the slightest duplication of code is orders of magnitude a bigger problem than duplication in production code might be, because tests come in large numbers on each class or even function.

 

So, does all this mean you should still use Setup and TearDown? Not necessarily. You can still remove duplication and  keep your tests fairly readable by following a few simple rules.

The three rules of test duplication are:

Never instantiate objects inside a test - always use a factory method

instead of

[Test]

public void Create()

{

MyOBject x = new MyObject();

} 

 

do:

[Test]

public void Create()

{

MyOBject x = makeDefaultMyObject();

}

 

private MyObject makeDefaultMyObject()

{

return new MyOBject();

} 

 

 

Refactor configuring(preparing for test) object state into shared methods (not static, but common to be used by multiple tests)

 

Refactor duplicated Act-Assert combinations into common methods (very methods)

 

Instead of