Image courtesy drivethrucafe; license
A few months ago, I got caught up in a series of contentious debates about duplication in test code. I’m the sort who believes that most of our design heuristics–simple design in this case–fall victim to the reality of the pirate’s code: “The code is more what you’d call ‘guidelines’ than actual rules.” Which is OK by me; rules are made to be broken.
Unit tests are different beasts than production code. They serve a different purpose. For the most part, they can and should follow the same standards as production code. But since one of their primary purposes is to provide summary documentation, there are good reasons to adopt differing standards. (I solicited some important distinctions on Twitter a few months ago; this will be fodder for an upcoming post.)
With respect to Beck’s four rules of simple design, many have contended that expressiveness slightly outweighs elimination of duplication, irrespective of being production code or tests. With production code, I’m on the fence.
But for tests? The documentation aspect of tests is more relevant than their adherence to OO design concepts. Yes, duplication across tests can cause some future headaches, but the converse–tests that read poorly–is a more typical and bigger time-waster. Yes, get rid of duplication, absolutely, but not if it causes the readability of the tests to suffer.
My dissenting converser was adamant that eliminating duplication was king, citing Beck himself in Test Driven Development by Example (2002), on page one, no doubt: Step four in the rhythm of TDD says you run all the tests, and step five, “Refactor to remove duplication.” In that summary of steps, Beck suggests no other reasons to refactor! I can understand how a literalist-slash-originalist might be content with putting their foot down on this definition, never mind that “refactoring” has a broader definition anyway, never mind Beck’s simple design to the contrary, and never mind 14 years passage in which we’ve discussed, reflected, and refined our understanding of TDD.
Why a contentious debate? The dissenter was promoting a framework; they had created some hooks designed to simplify the creation tests for that framework. A laudable goal, except for the fact that I had no clue what the tests were actually proving. That just wads my undies.
Where am I going with all this? Oh yeah. So as I watched the dissenter
scroll through some of their tests & prod code onscreen, I noted
this repeated throughout:
public void doSomeStuff() {
this.someField = someMethod();
int x = this.someField + 42;
// etc.
}
Apparently their standard is to always identify field usage by scoping
it with this. (I bit my lip, because at that point I was weary of the
protracted debate, and figured I could write about it later. Here I am.)
“Hey, over-using this might be a good idea, because we can more easily
identify where fields are used, which is important information!”
OK, I’m offended that duplication-monists don’t view the use of this
in this case (i.e. not to disambiguate) as unnecessary duplication. It
is. Squash it. Instead, use the power of your sophisticated IDEA or
Eclipse IDEA, and colorize fields
appropriately.
(I like orange.) They’ll stand out like sore thumbs.
Related posts
Pingback: The Compulsive Coder, Episode 1: The Stub Comment
Pingback: The Compulsive Coder, Episode 2: Syntax Coloring
Pingback: The Compulsive Coder, Episode 3: Typing Isn’t the Bottleneck
Pingback: The Compulsive Coder, Episode 4: You Create, It Assigns
Pingback: The Compulsive Coder, Episode 5: Extract Method Flow
Pingback: The Compulsive Coder, Episode 6: this Duplication is Killing Me
Pingback: The Compulsive Coder, Episode 7: Please AAA
Pingback: The Compulsive Coder, Episode 8: You Might Not Like This
