Sam Stokes wrote:
Jonathan Linowes wrote:
I make some limited use of global (instance) variables that
correspond to english language pronouns. I have things like
@current_user (corresponds to "I"), @current_project (corresponds to
"the project"), etc. I am careful to be consistent. There's only a
handful of these, but I find it extremely convenient. Note, these
also tend correspond to 'states' in my app, which might be in the
session or part of a nested URL.
So could I summarise this approach as, "use @variables, with good names
and consistent principles for use"?
I'm of the opinion "do what works". I know there are purists that say don't do this and don't do
that, but when you come down to it you have to use variables between steps, look at the rails
examples and it sets a response variable between steps.
What I do is horrible :) but "it works", I set GLOBAL variables (yup $current_state), because I
found that sometimes @variable didn't get setup properly in some cases.
Then I use the listeners to clear those variables between scenarios, so every scenario I have a
listener (effectively before_scenario), that clears all the global variables I use between steps,
this avoids errors where I don't set up something in a step but the scenario passes because it just
happens to have the right value in a global set by a previous test.
This does require some maintenance, however I could use a global hash for my
inter-step-dependencies, and just $hash.clear in the before_scenario listener.
Ahh I remember why I had to use $variable and not @variable, for some reason the before_scenario
listener does not have access to the same scope as the scenario so I have to use $variables.
So most of my scenarios look like this....
before_scenario do
$v1= nil
$v2= nil
end
Scenario "xxx" do
Given "something..."
When "I do something" # this will set $v1 and $v2
Then "check it was done" # this will check $v1 and $v2
end
I know purists will hate this ;) But "it works for me"
BTW I use stories entirely for integration testing, testing the entire stack by using the same
inputs (in my case a WEB based REST API) to the stack as a client would.
I also do nasty things like delve into the database directly in a Then to check the database
actually got setup the way I expected by a previous When, as well as checking the returned XML from
the Rest-API call.
As always YMMV
--
Jim Morris, http://blog.wolfman.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
