Saving the DRY-Dogma

Recently (well some time ago, but I am thinking at a leisurely pace) Jay discussed how he thinks, that DRY is not neccessarily the most important thing, when it comes to writing tests. As I a am working on a huge (by agile standards) project for a while now, I feel very dogmatic about DRY, and OAOO. If you have duplication it will spread – quickly.

But on the other hand I see, what he means by readable test code. A lot of problems I had with the naive approach of reuse in test classes was about trying to uses classes and class hierarchies to reuse code. If the set up happens magically it is quite difficult to figure out what’s going on.

So how could the DRY dogma and the requirement of readability be reconciled?
I would rephrase DRY to say:”Do never ever repeat the how something is being done, but you my very well repeat the what is being done in different contexts.” So I relentlessly refactor my code to a more declarative style and then go ahead and happily duplicate the declarative statement.

One Comment

  1. Good tip.
    In other words, extract duplicated functionality and put it inside well named methods (focusing on the “what” as any well named method is) and call it from each test whenever you need it. The power of the “extract method” refactoring.

Leave a Reply