Is duplicated code more tolerable in unit tests?

Question

I ruined several unit tests some time ago when I went through and refactored them to make them more DRY--the intent of each test was no longer clear. It seems there is a tr

Answer 1

I don't think there is a relation between more duplicated and readable code. I think your test code should be as good as your other code. Non-repeating code is more readable then duplicated code when done well.

Answer 2

I feel that test code requires a similar level of engineering that would normally be applied to production code. There can certainly be arguments made in favor of readability and I would agree that's important.

In my experience, however, I find that well-factored tests are easier to read and understand. If there's 5 tests that each look the same except for one variable that's changed and the assertion at the end, it can be very difficult to find what that single differing item is. Similarly, if it is factored so that only the variable that's changing is visible and the assertion, then it's easy to figure out what the test is doing immediately.

Finding the right level of abstraction when testing can be difficult and I feel it is worth doing.

Answer 3

Ideally, unit tests shouldn't change much once they are written so I would lean towards readability.

Having unit tests be as discrete as possible also helps to keep the tests focused on the specific functionality that they are targeting.

With that said, I do tend to try and reuse certain pieces of code that I wind up using over and over, such as setup code that is exactly the same across a set of tests.

Answer 4

I agree. The trade off exists but is different in different places.

I'm more likely to refactor duplicated code for setting up state. But less likely to refactor the part of the test that actually exercises the code. That said, if exercising the code always takes several lines of code then I might think that is a smell and refactor the actual code under test. And that will improve readability and maintainability of both the code and the tests.

Answer 5

You can reduce repetition using several different flavours of test utility methods.

I'm more tolerant of repetition in test code than in production code, but I have been frustrated by it sometimes. When you change a class's design and you have to go back and tweak 10 different test methods that all do the same setup steps, it's frustrating.

Answer 6

I LOVE rspec because of this:

It has 2 things to help -

• shared example groups for testing common behaviour.
  you can define a set of tests, then 'include' that set in your real tests.

• nested contexts.
  you can essentially have a 'setup' and 'teardown' method for a specific subset of your tests, not just every one in the class.

The sooner that .NET/Java/other test frameworks adopt these methods, the better (or you could use IronRuby or JRuby to write your tests, which I personally think is the better option)