Moist Tests: Production Code Needs to be DRY, But Tests Don't

I've spoken a bit about this before when discussing our standard_params notation. I think we've taken the DRY principle too far. And I think this happens a lot in the software industry. We latch onto a good principle, and our meticulous (some would say anal) natures lead us to want to apply it everywhere. And we do it with DRY. Don't Repeat Yourself. Removing duplication in code removes bugs. Re-use promotes efficient development. It's a fantastic principle, first outlined by Dave Thomas and Andy Hunt in The Pragmatic Programmer. It's probably still underused in most code bases. But one area where I see it abused is in tests. Tests don't need to by DRY, they can be Moist*. Take these two tests for example:

def test_formatted_telephone_number
  telephone_number = TelephoneNumber.new(:area_code => "123", :telephone_number_base => "5556811")
  assert_equal "(123) 555-6811", telephone_number.formatted
end

def test_unformatted_telephone_number
  telephone_number = TelephoneNumber.new(:area_code => "123", :telephone_number_base => "5556811")
  assert_equal "1235556811", telephone_number.unformatted  
end

DRY would see the duplicate creation of the same TelephoneNumber object, and say "Extract Method" to remove the duplication. Or perhaps we could stick an instance variable in our setup, and assign the TelephoneNumber object to it there:

def setup
  @telephone_number = TelephoneNumber.new(:area_code => "123", :telephone_number_base => "5556811")
end

def test_unformatted_telephone_number
  assert_equal "1235556811", @telephone_number.unformatted  
end

And if this wasn't a test (if it was actual code that will be executed in production), I would definitely agree. If you remove the duplication, you only have one place to change the code when that time arises, and bugs are less likely to result. But in tests it is different. When a test fails, I want to fix it quickly. And when I have to search around a large test class for extracted methods, or instance variables that may be modified throughout the class, this costs me time. And I'm willing to accept the risk of the duplication causing a bug (after all, it is only test code) if I reduce the time wasted.

So for me, private methods in test are a smell. So too are setup methods. The only time I use them is when I can get the abstraction such that I very very rarely have to look at what is happening beneath the abstraction. A good example is rails' Controller tests. They have a setup which initializes the controller, and a request and response object. I think I can count on one hand the number of times that I've had to care about these variables, so in that case, it's ok.

*I believe zak came up with this term, though I'm not sure. It may have been Jay Fields. Either way, I'm certainly not taking credit.