On Jun 17, 2008, at 10:41 AM, Ben Mabey wrote:
David Chelimsky wrote:
Reordered your posts so my comments make sense (we prefer to avoid
top-posting - even though I sometimes violate that myself :) ).
On Jun 16, 11:58 pm, Jim Morris <[EMAIL PROTECTED]> wrote:
I'm not using Rails, I am doing end to end integration testing
talking
to the server via net/http, so RailsStory is not involved.
Cool. Are you talking directly through ruby constructs or through a
browser tool like selenium?
I think the listeners may do it, I can use story_started like
before(:all) and story_ended like after(:all) which will be great,
presuming story_ended is always called even after a failure.
Yep.
However I am missing the place where that listener gets
registered, I
am using the...
Story "description", %{...}, :steps_for => steps do
Scenario "sdsdsd" do
...
end
end
syntax, so where is the listener set?
Thanks
On Tue, Jun 17, 2008 at 2:28 AM, Jim Morris <[EMAIL PROTECTED]>
wrote:
Ahh ok think I found it...
In my test file at the start...
class MyListener
def method_missing sym, *args, &block
# ignore all messages you don't care about
end
def story_started(title, narrative)
puts "...Started story #{title}"
end
def story_ended(title, narrative)
puts "...Ended story #{title}"
end
end
Spec::Story::Runner.register_listener(MyListener.new)
Yep. That's the right way.
Then I define my steps using StepGroup.new
You can just use the steps_for method and it'll still work.
Then the Scenarios
It seems to work although not very intuitive :)
I'd prefer a before(:all) and after(:all)
I'm not with you on that, but I'm open :) We could solve the OP's
problem with something like this:
Before Each Scenario:
Log in as admin
Scenario: editing private data
...
Before Each Scenario would match a Given step definition "Log in as
$role" or something like that.
I'm just not sure this really heads us down the right path. Next
thing
you know we'll have Before Story, After Each Scenario, After Story,
etc and the stories are going to start looking less and less like
stories and more and more and more like code, at which point you
should be using example groups instead :)
Anybody else have opinions about that?
Cheers,
David
I *really* don't like the idea of having a "Before Each Scenario" or
similar construct. I have already seen abuses of the story runner
where the stories look too much like code/examples. I think adding
such language to the story runner would really hurt and confuse the
original intent of stories. I'm not questioning whether such an
addition would be helpful, I think it would and I may at times use
it.. but IMO it would only be helpful to the developers point of
view and I don't see it really adding much value to the stories. If
someone can offer an example where they think such language would
help the stakeholder I would be interested but to me it is starting
too look too much like examples.
Like Kyle said in a previous post, I think a better way to handle
these situations is to rely on the fact that having an admin be
logged in is somewhat implicit in the story and that the
implementation can be handled under the covers, so to speak, with
helper methods within the steps. This of course will require you to
call the same helper method for all of your first Given steps. So I
guess this is where the pain point is.. but it doesn't seem to be a
big one most of the time.
The Listeners are good for application-wide/story suite wide setup
and cleanup, like databases as such. Placing the login of an admin
into a listener would obviously be overkill unless all of your
stories involved an Admin being logged in. What people seem to
asking for is more control over the granularity of which stories a
particular listener effects. Say, for example you have a set of
stories that all require that an Admin account to exist with certain
permissions and that the admin is logged in. What if you could
define your AdminSetupListener and then hook it into the runner for
your stories like so:
with_steps_for
(:admin_section, :webrat).and_listeners_for(:admin_setup) do
run_story(File.expand_path(__FILE__))
end
This could provide the setup/teardown capabilities for a certain set
of stories without polluting the Story language.
Does that make sense what I'm suggesting? I'm not sold entirely on
it myself. It seems to add yet another layer of abstraction to help
DRY up the steps and in so doing spreads the story's executable code
throughout even more files. This could hurt maintainability so I
think the use of this could also be abused... but if people want
more granular control in there setup and teardown with the Stories I
would vote for an option like this instead of placing it in the
actual Story language/parser itself.
I hope most of that makes sense. :)
Perfect sense to me :)
Cheers,
David
-Ben
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
