For example, look at these two specs and think about which is cleaner and easier to understand:

specify "user should supply name when registering" do
  @user = User.new(:name => "David")
  @registry.should_receive(:user_name).with("David")
  @user.register(@registry)
end

specify "user should supply name when registering" do
  @name = "David" 
  @user = User.new(:name => @name)
  @registry.should_receive(:user_name).with(@name)
  @user.register(@registry)
end

For me, the first one is simpler. No question. There’s one less line of code (that’s 25% in this case), I can clearly see the name and I don’t have to mentally decode the meaning of @name – nor do I need to look around to see where else it might be used. Remember, temporary variables are a code smell too.

The reason that I believe DRY to be important is that when you have duplicated code you run the risk of changing it in one place and forgetting to change it in another. If you do that, you’re likely to introduce bugs. That is the real risk – not the fact that you might have to type things more than once.

You could make the argument that the second example above manifests this risk. So in that case, you have to weigh clarity and DRYness and make a choice. I’ll usually choose clarity in tests.

There are other examples in which I really don’t think this risk is real. One is multiple calls to a no-arg method. This came up in an email thread on the rspec-users mailing list. The poster was looking for a way to avoid writing a line of code that logs in a user in many different rspec contexts.

The line to avoid was …

session[:logged_in] = true

... and I recommended including a module …

module LogIn
  def log_in
    session[:logged_in] = true
  end
end

context "Given a logged in user..." do
  include LogIn
  setup do
    log_in
  end
  ...
end

The poster responded that he was concerned that there is still duplication because you have to type the two statements in every context.

I see a difference between duplicated statements and duplicated calls to a no-arg method. While typing the call to log_in may require a few extra strokes, the meaning of it will never change in different contexts. So the risks associated w/ code duplication are mitigated. In fact, the real risk is that you might change its one and only meaning, in which case you’d have to look at each case and decide if the new meaning makes sense.

That problem wouldn’t go away if you could subclass contexts. In fact, it would be more sinister because the behaviour is implicit. At least if you look at log_in in each context you have some sense of what it means.

In summary, I believe strongly that DRY is a very important principle. But it’s not the only principle and it definitely isn’t implicitly the most important principle to apply in every situation. Sometimes a little moisture can be just the thing you need to clean up your code.