Hi Jim. I guess I'm not a purist then - that looks fine to me, and it's probably something I would consider doing too.
The thing to bear in mind is that there is magic going on when you run steps. Each step in a scenario is run in the context of the same object instance (which you don't get to see explicitly) by pixies, which means any @variables you set in one step should be visible to any other steps in the same scenario. I don't think of this as global state - it's simply a sensible way to share state across steps. You can think of the object the steps run in as a "world" (it might even still be called that - it was at one point) where you can set and verify state. There are bound to be pathological cases though, such as the before_scenario and after_scenario listeners. Perhaps there's a bug there, in that they should be running in the same object instance as the scenario steps themselves. Perhaps not. In the latter case I would definitely go with $globals to communicate state into your scenario, as long as you promise never to use them in your application code. Never, you hear me? Cheers, Dan 2008/9/8 Jim Morris <[EMAIL PROTECTED]> > 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 >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
