Comments on Beech Bonanza: Moist Tests: Production Code Needs to be DRY, But ...

You need to differentiate between test-cases and s...

2008-08-22T13:20:27.953-07:00

You need to differentiate between test-cases and support code.

Tests tend to have repeating support code (especially if the Testing Framework used does not support the technology needed, like creating sample documents, threading, mocks or stuff.

It is not a good idea to have 5 lines of DOM Parser code in multiple places when all you need is a instance of a fixed XML fragment.

It is much better to have a private "createDomFromString()" or "initialiseMockServer(p1, p2, p3) or "validateDomElement(dom, key, value)" than to repeat that code.

In the end the tests get more human readable as well.

Gruss
Bernd
--
http://itblog.eckenfels.net

*Multiple Occurrences of Identical or Similar Text...

2007-08-24T20:23:34.329-07:00

*Multiple Occurrences of Identical or Similar Text (MOIST)

I'd go a step further. It's not just about fixing ...

2007-07-28T04:35:19.059-07:00

I'd go a step further. It's not just about fixing broken tests... in Agile, we talk a lot about how our tests are our documentation. When I want to understand how a class works, I'll often read the tests first. When I'm trying to get a handle on a new codebase, it's frustrating in the extreme if I have to continually jump out to setup methods and object mothers to see exactly what the important parts of my test objects are. (This is even more frustrating if your team uses an underpowered "IDE" (read as: "text editor") like TextMate where you can't easily jump to method definitions.) I don't mind having a generic "default" object set up somewhere else, as long as every test modifies the pertinent fields within the test body itself so that I can read them.

Hi Dale, On my current project we have 6 devs and ...

2007-07-27T17:22:26.676-07:00

Hi Dale, On my current project we have 6 devs and have been working for a year - we don't have a huge problem with test maintenance. If we keep to a convention we can make changes pretty quickly using regular expression search/replace, but my regex skills have had to improve a bit, I must say. I really like your last comment about taking code out that isn't specifically relevant to the piece of functionality. This is really important. It's really hard to get the abstraction right (ie choosing exactly what to take out, and what to leave in). Not many developers seem to understand and/or care about the subtleties of abstraction. I'm interested in this concept and trying to put together something on it. Thanks for your comments...

DRY is not just about reducing bugs. It is also ab...

2007-07-27T10:14:25.189-07:00

DRY is not just about reducing bugs. It is also about reducing maintenance and refactoring costs.

I agree that your approach makes reading tests much simpler.

I've tested this approach on a bigish project (8 devs - 6 months). Test maintenance did become a serious issue towards the end.

Have you followed this on large projects? did it scale for you?

I believe there is a balance here. If you have setup code that isn't specifically relevant to the piece of functionality under test I think you can factor this out. But not necessarily into a private method. Pushing this stuff out sideways into a sensible testing domain model will provide more reuseable code.

Just my 2 pence.

Hey, nice post, i totally agree with you. I've see...

2007-07-27T07:08:56.055-07:00

Hey, nice post, i totally agree with you. I've seen people abuse the DRY principle, will point them to you blog entry the next time.