[rspec-users] DRYer controller specs

[nicholas a. evans]

On 4/27/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> I like the idea of binding the examples to some method that gets run
> before or after the example. There is a similar RFE already in the
> tracker http://rubyforge.org/tracker/?func=detail&group_id=797&aid=10285&atid=3152.

I hadn't seen that one.  I was originally also thinking about some
sort of magic handling whereby mocks are automatically run before and
state expectations are automatically run afterwards.  But I agree with
you: that magic comes at the cost of losing much clarity.

> The problem is coming up with the right language.

Yes.

> In the RFE I mentioned, I proposed something like ...
>
>   it "should do something", during_event do

I like that a *lot*.  :-)

> That seems to work well, but its counterpart ...
>
>   it "should leave some state", after_event do
>
> leaves me cold. It especially fails to align w/ your example "should
> assign new person to template on GET to create", which seems like a
> great way to express the behaviour, but followed by "after_event"
> doesn't really read correctly.

Could during_event, before_event, after_event, when_event,
by_end_of_event, on_event (and perhaps some number of other aliases
with the same similar before/after behaviour, but different names for
readability in different contexts) also be made to append text to the
specification string?  Likewise, the event itself could include a
description.

e.g.

describe PeopleController do
  before do
    @person = mock_model(Person)
    Person.stub!(:new).and_return(@person)
  end
  event "GET to #create" do
    get "create", :foo => "bar"
  end
  it "should create a new person", during_event do
    Person.should_receive(:new).and_return(@person)
  end
  it "should assign new person to template", on_event do
    assigns[:person].should_be @person
  end
end

could generate the following sentences:

PeopleController should create a new person during GET to #create
PeopleController should assign new person to template on GET to #create

What do you think of that?  I'm still not sure that "on_event" clearly
represents "event then expectation" as clearly as something else
might... but it works for me, and it produces the nice string.

> In general, I'm much more inclined to favor an additional parameter
> passed to #it over a new method name.

Yeah, I hadn't even thought about something like that.  I like it a *lot*.

-- 
Nick