SetUp and Teardown Methods in Test Classes

Jim Newkirk is blogging about the down side of setup and teardown methods in test classes, and why you shouldn’t use them.

Setup and teardown methods attract entropy faster than an outsource programmer with his first patterns book.

Jim’s new framework, xUnit.NET doesn’t have primitives for setup and teardown, although it sounds like there are mechanisms that could be used to accomplish the same kind of thing.

Roy feels that xUnit.NET isn’t quite there yet.  I think that Roy’s perspective will be reflected by lots of folks who have become used to NUnit (et al) over the past six years.

I think that Jim is on the right track, but I’m the kind of guy that feels that a test class’s greatest responsibility is to document behavior in the clearest possible way, even if that means sacrificing design qualities best reserved for functional code – like reuse.

Unit test patterns in .NET can learn a lot from RSpec, where setup and teardown methods, as well as test methods themselves, are kept small – tiny, actually – by breaking up multiple test classes into smaller, more focused modules.

An RSpec context (“Describe” block) doesn’t have a direct equivalent in .NET and NUnit, but the spirit of a test context can still be achieved.

A context is typically smaller than an xUnit test class.  Because it’s smaller, it avoids a significant contributor to test class entropy.

Here are a couple practices that I use in RSpec to keep entropy at bay that are also applicable to unit testing practices in .NET:

  • Don’t put anything in a setup method that doesn’t pertain to every test method in the test class
  • If you have stuff in a setup method that doesn’t pertain to each test method, break up the test class into multiple test classes where the instance members initialized in the setup pertain to each test method in the new test classes.
  • These new, smaller test classes are test “contexts”.
  • Keep related contexts in the same file.
  • When you get four or five test methods in a single context, consider whether the test methods are related to the same concern.  If they’re not, break up the context.
  • Name contexts for the concern.
  • Name test methods to describe the experience of the concern under test, not the implementation of either the test or the functional code.
  • If you can’t see the setup method on the same screen and in the same glance as the test methods, break up the context.

The problem with setup methods has to do with solubility.

Loading setup methods up with initialization that doesn’t pertain to each test method and having test classes the scroll on out of sight saps solubility.

If you really want setup behavior in xUnit.NET, I bet you can figure out a way to make that happen.  However, Jim and Brad are giving you a chance to reconsider your own testing practices in light of their extensive experience, and in light of emerging beliefs about unit testing and test-driven practices as they continue to evolve based on the discoveries of some of the field’s most persistent explorers.

This entry was posted in Agile, Design, Solubility, Test-Driven Development. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Leave a Reply