[rspec-users] DRYer controller specs
nicholas a. evans
nick at ekenosen.net
Fri Apr 27 11:36:44 EDT 2007
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.
> 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
describe PeopleController do
@person = mock_model(Person)
event "GET to #create" do
get "create", :foo => "bar"
it "should create a new person", during_event do
it "should assign new person to template", on_event do
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*.
More information about the rspec-users