[rspec-users] Common setup code and naming specifications

Fri Jan 5 04:25:29 EST 2007

David Chelimsky wrote:
> Ah, the DRY battle cry.
>   

Yeeehaaa! :)

> There is a difference between duplication of code and duplicated calls
> to a no-arg method. While typing the call to set_logged_in may require
> a few extra strokes,

You're right. At least in this particular case there would be no gain in
having something like a logged_in_context-"base class". It wouldn't save
very much keystrokes and it doesn't communicate better than putting
set_logged_in in the setup. If there's common setup code, it should be
refactored into a helper module and included in the context.

> are inherently procedural. The risk of duplication in code is that
> when you have to change it in one place you'll miss the other place.
> That risk doesn't really apply to this situation.
>   

The only thing I'm constantly missing is putting the logged in code in
the setup, when creating a new context. But a subclassing approach
probably wouldn't make this any better. Maybe I just shouldn't code at
one o'clock in the night :-)

>> Excellent point. There's no simple answer for this. Your best bet is
>> to keep throwing examples at us and we can discuss them more
>> explicitly.
>>     

>From another point of view, one might also see it this way:

Not putting implementation details into the specification title gives
you more freedom to implement it along the way. In this sense I would
describe the anatomy of a specification as:

specify "<title>" do
    <body>
        <usage>
        <verification>
    </body>
end

The <title> should be a hint on what functionality / behaviour is
specified. <body> describes the details and typically consists of a
<usage> part and a <verification> part. The customer does only look at
the title. The developer, who e.g. implements the view, looks mainly at
the <usage> part. This can also look like:

setup do
    <usage>
end

specify "<title>" do
    <verification>
end

Maybe this can be seen as a pair of different languages in a
translation. <title> is a phrase in the human customer language, <body>
is the translation in the developer language. Mmmm... thats still not
the right analogy. It's more like a dictionary where <title> is a term
in one language and <usage>/<verification> is the definition in another
language.

Ok, before I get too philosophical about this, I'll rather go ahead and
write some code to see where this gets me :-)

Regarding the examples - what I'm currently working on is open source
anyway. I'll put it into a public SVN repository these days, so if
anyone is interested he can take a look at it.

bye,

Tobias