[rspec-users] DRYer controller specs
dchelimsky at gmail.com
Fri Apr 27 11:53:29 EDT 2007
On 4/27/07, nicholas a. evans <nick at ekenosen.net> wrote:
> 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
> before 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
> assigns[:person].should_be @person
> 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.
Very nice! The trick is that we're merging to concepts here - trying
to express the intent of the example and also have it execute the
right things in the right order. Words like "during" or "on" are there
to coerce rspec to execute things in the right order but they mean the
same thing to me in terms of expressing the example - the "when" in
GWT. I'd love to come up with words that serve both execution and
expression equally. Any other ideas?
> > 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*.
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users