On 1/4/07, Tobias Grimm <listaccount at e-tobi.net> wrote:
> Thanks for your fast response!
>> David Chelimsky wrote:
> > context "..." do
> > include MyHelpers
> > setup do
> > set_logged_in
> > end
> > end
> >
>> Ok, but this still requires me to call set_logged_in in 99% of my
> controller contexts. I can live with it, but it tastes like evil
> duplication.
Ah, the DRY battle cry.
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, 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 set_logged_in in each context you have some sense of
what it means.
There is also a difference between duplication in code and duplication
in tests. Jay Fields put it very well when he put it this way: test
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.
Alternatively, you could figure out a way to subclass contexts and not
be able to look at a given context and understand why the user keeps
on ending up logged in.
My only slightly solicited 2 cents.
>> >> specify "should provide the first ten items in @items and three pages in
> >> @pages when passing no :page parameter to the :list action"
> >>
> >> specify "should provide the first ten items and three pages when not
> >> selecting a specific page"
> >>
> >
> > Definitely the latter. These names should be how the customer would
> > talk about requirements, not how developers would - UNLESS you're
> > writing a framework for developers and developers ARE your customers.
> >
>> Fine - sounds reasonable! But sometimes it's hard to see, whether you
> are working on a framework or not. If I'm at a controller, it's not only
> the customer who uses it in some way, it's also the view. And the view
> needs to call :list and pass :page and expects to get @items and @pages.
> The second of the two specifications above tells nothing about how the
> view should interact with the controller.
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.
Cheers,
David
> Tobias
>> _______________________________________________
> rspec-users mailing list
>rspec-users at rubyforge.org>http://rubyforge.org/mailman/listinfo/rspec-users>