Your test code is production code. Treat it the same way. Don’t let cruft build up, and follow good software engineering principles – like Don’t Repeat Yourself (DRY).
I was looking through some test code the other day and found a great opportunity to refactor out some common behavior to a factory. I do this quite often in the test frameworks I build – shove off responsibility for data and object creation to a factory so I can keep things much clearer in my tests.
In this case, we’re testing a parser class that creates reports based on an XML file. A number of tests check the parser’s handling of malformed XML or missing elements. The basic pattern below is repeated across eight or nine tests: hardwire an XML string in the test, feed that to the parser, then check if appropriate errors and messages are generated by the parser.
This is repetitious, duplicated, copied cruft. Small joke there. Moreover, it’s not readily apparent what the XML snippet’s intent is. I have to read the entire XML, then mentally unwind what I know of the structure to figure out that, oh, this snippet is actually missing the title element.
Compare the above with this section of refactored code:
The implementation of the TestReportFactory isn’t overly important ; what’s important here is that duplicated behavior should be pushed out to a common area, regardless of whether it’s in the system under test or your test code itself.
Your tests are production code. Treat them as such!
(NOTE: Some folks, particularly the Really Smart Guy Jeremy D. Miller, make the absolutely solid case that you should never sacrifice readability in your tests for the sake of cutting duplication. It’s good to push duplicated behavior out if you can keep your tests completely clear. It’s not ok to push behavior up to base classes or elsewhere if your test turns into a vague skeleton. Readability trumps everything else.)
 The TestReportFactory simply builds up a string of XML, creates an XElement from that, then uses XElement.remove() or XAttribute.remove() to drop elements or attributes as needed. The entire class is pasted below. Yes, there are a number of other ways to skin this cat. I could make things a bit more dynamic, but this worked for what I needed right now. And yes, I drove design and implementation of this factory with a separate set of tests I wrote first…