« NUnit Converter V1.1 - Moved from GotDotNet | Main | Ridiculous Legalese »

September 15, 2007


Feed You can follow this conversation by subscribing to the comment feed for this post.



Why do you treat SetUp and TearDown features as a problem?

If you don't need to use these attributes - don't use tehm!

These attributes are not just for splitting code - they are designed to be used is test running mechanism. We have 3 projects with 900 tests + in each of them. SetUp and TearDown attributes are extemely helpful.

Mark Levison

When methods under test require a different setup/teardown I tend to think that I'm trying to test too much in one class. So I usually split out separate test classes usually sharing a common base.

Like many of the others I still find setup/teardown useful I just use them judiciously.


Chris Prinos

I think there are some big downsides to removing SetUp/TearDown:

1) By redistributing the setup code to all of the test methods, you've made it more difficult to make a simple change to the pretest configuration. Instead of changing SetUp, you have to go and change all of the individual methods.

2) Without an api hook into the pre/post test actions, you lose the ability to derive from a parent test case class and inherit it's setup.

3) From a reporting standpoint (though not all x-unit frameworks do it this way) I think it's important to separate failures in test initialization compared to the test itself. Though less common in true unit test scenarios, if you are using the framework for integration or driving UI tests, the SetUp may contain a significant number of steps and error handling (e.g. a lot of code that you don't want duplicated in many test methods). In principle, I like to make the SetUp/TearDown methods very robust and able to 'clean up' various application states, whereas I like the actual test methods to be more sensitive so that they will show failures if something doesn't go right. It's hard to get that split without separate methods for SetUp/TearDown.

Having said all that... I use TearDown infrequently and tend to make sure SetUp can clean up & initialize as needed. I could probably do without TearDown, but not without SetUp.

Suite-level set up in addition to test-level setup (whether the suites are static, or built dynamically via some type of test query/filtering) is also really helpful.

Martin Platt

But isn't moving the setup and teardown code into each test a little like saying that class hierarchies are too complex, we should use monolith code, functional programming of course?

Think the example of including the setup code in the tests is a bit like a hello world example, if it were using Mock objects, or the tests were a little more involving, and there was a lot of shared functionality, then it would quickly become unreadable to repeat in each test.

I can partly agree with your argument, in that I have seen plenty of setup and teardown methods used to perform repeated code. Personally, I think that they should be in their own private method that can be called at will, and is well defined and understood in the code. Badly named methods are a completely different topic, and I don't think 'Initialize' really cuts it, nor does setup and teardown for performing specific functionality.

To me, teardown sounds like ripping something down that you might have built, thus, from that naming, I would summarise that setup is something that you build for your tests to work.

So, I think all in all, setup and teardown are fine, but they should be used properly, and not for code that actually performs the tests.

Christoph Wienands

He correctly recognizes that the BeforeTest() does not have any common functionality. However, choosing a poor example to prove ones point does not mean the SetUp and TearDown should be removed.

Out of my head I can come up with plenty of examples where these initialization/clean-up methods make perfect sense, because they do things COMMON to all tests. Here are some of them:
-Reset member variables
-Remove left-over files (especially after failed tests)
-Initialize/clean up a database

If there are distinct test groups that share distinct initialization/cleanup functionality tests, maybe it's time to split up that test fixture along the distinct test groups and properly factor out that duplicated i/c code.

Again, in my opinion no reason to remove some completely valid functionality.

James Newkirk

I guess we will agree to disagree. You can say I picked a bad example but in my experience I picked one that I see repeated over and over.

I also don't believe these classes should have member variables so there would be no need to reset member variables.

I do agree that you should split your classes up and make smaller fixtures and when I do this I have even less need for Setup and Teardown.

The comments to this entry are closed.