This second point creates a natural tension between DRY and readability. In other words you could do the first one and still end up with examples that were too DRY to read easily. The second issue is the more important one for me – especially if your testing/example framework executes potentially hidden methods that alter the flow of the example.

August is traditionally the startup month after the summer for NNUG activities and NNUG Bergen has really…

Thanks for valuable insights. But I’m getting a little bit confused here. I read you to say that the test cases should read like stories, and that moving supporting classes and methods “just ahead of the first test that used them” achieves that. But you still DRY them, don’t you? So aren’t you actually arguing for letting the examples flow more than against DRYing? DRYing is not necessarily “moving out of the way”.

On the other hand, how far do good, descriptive names take you so that you don’t even need to move the definitions up-front in order do understand the story? Why didn’t inlining self-descriptive calls do?

Yes, you’re right. In my IDE I’m only one keystroke away from the definition of any helper method. But here’s the thing. I could describe to you that to get to the dining room you have to go through the kitchen. We all know what a kitchen is. We all have a kitchen, we’ve all seen lots of other ones. To understand this specific example it doesn’t matter what this particular kitchen looks like.

But if I had a description of the kitchen for this example it would make it just a little more real for me. This kitchen is a narrow galley kitchen. It has storage on one side (the left), good lighting coming from both a skylight and a double window (straight ahead), and it has an electric oven with a four unit gas hob.

If I wanted I could hit F3 to see the description of the kitchen, but I probably won’t bother – I already have a generic “kitchen” in my head I can refer to. However if the description of this particular kitchen appears just ahead of the example, it makes it a little bit more vivid. I’m not suggesting to duplicate the description every time, just to put it ahead of the first example that refers to a kitchen so that I’m not substituting my generic one.

By reordering the helper methods and classes you can make it that little bit easier for me to be in the same headspace that you were when you wrote the example. Charles “cowboyd” Lowell, the man who taught me TDD, sums it up really nicely

As a side note, I’ve considered for a while now that there are several cases apart from just testing when it helps to distance yourself from (though not abandon) DRY. I did a write-up awhile back about how I strategically violate DRY in my day to day coding, and why it actually makes my designs and my code better.

Have a look homie, and let me know what you think.

http://www.thefrontside.net/blog/repeat_yourself