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

first of all in my not so humble opinion the DRY-Dogma has to be defended and there is no real exception. We know that test cases are prone to receive too little maintenance, so a bit of DRYness is essential!

Hgs points to the solution of your dilemma, when he says that the non-DRY version should be generated. Wasn’t this what the StoryWriter thingy in JBehave was all about? Essentially you would like to have an execution trace. You might even improve that by annotating/ instrumenting your test code with special story output.

If you think about acceptance tests it wouldn’t necessarily be a textual thing. You could use a screen capture tool in conjunction with selenium and actually produce a video (potentially adding special logging that get’s rendered as subtitles in the video (or refers to an audio file)).

Felix had a good post about this at the link below. To summarize – Duplicating the ‘what’ is less evil than duplicating the ‘how’. You can achieve this by refactoring to declarative Setup and Assert (sorry – Given and Then). If you haven’t already you should read the post.

http://wuetender-junger-mann.de/wordpress/?p=582

But generally it is difficult to lookup ideas in a story, unless they are broken down into chapter and verse, and even then one needs exegesis. This is one problem I’ve had with the business novels of Eliyahu Goldratt which teach Theory of Constraint. Trying to lookup the details of what constitutes “Drum Buffer Rope” is not really helped by the narrative structure. Also, narratives don’t have much literal repetition. I’m not sure what a DRYed out
novel would be like. It would be an interesting artistic experiment in itself. Maybe one could try it on something out of copyright, like Gulliver’s Travels.

I think you are onto something here, and I think given the concept of User Stories in Agile development, making the tests follow that flow makes sense.

I do wonder if the non-DRY version should be generated from a DRY version, though.