On Mon, Jan 12, 2009 at 11:49 AM, James Byrne <li...@ruby-forum.com> wrote: > Stephen Eley wrote: > >> >> On acceptance testing, I'd favor going through the actual session >> creation logic instead of mocking it, even if you don't put an >> explicit "Given" every time. Yeah, it's slower. But acceptance tests >> aren't _supposed_ to be fast; they're supposed to demonstrate real >> usage, and be the last line of defense between your app and the big >> bad world. They're going to be slow with or without login each time. >> And if there is some unseen routing or filtering bug in some >> controller's session access that doesn't show up in your test because >> you skipped past all that, and you lose a day and some hair trying to >> figure it out, you're going to wonder whether the seconds you saved >> were worth it. > > Ok, Ok, Ok... It is no big deal to login in every time. If that is the > way it should be done in general then I have learned enough these past > weeks that I will go with the flow and save myself some headaches. > > Thanks for the pointers and the explanations. I feel much more > comfortable about doing the login in each scenario now that I understand > the reasons.
Well you can inject it right into the session instead of doing the full webrat thing. That'll definitely cut down on the time it takes. btw, I know it seems like you want this stuff to persist between scenarios, but you really don't. You want to ensure that the world is in a known state before the test run, so that your tests are repeatable and reliable. Getting it into a known state requires two steps, basically (1) get to a base state that works for EVERY SINGLE TEST. This basically means an empty database, potentially populated with some seed data (like if you store references to zip codes in the db) (2) at the beginning of each test, modify the state to suit that test. You should be changing only the state that you need to write an expressive test, and no more If you need to reuse logic, take advantage of one of the existing reuse patterns. In cucumber's case, that means extracting code to a step and calling that in the scenarios. With RSpec, you've got a bit more stuff like nested groups with a before block (which imo is NOT a good idea for cucumber, nesting scenarios would be insane). What you're asking about is implicit coupling, and that's not an effective reuse pattern :) Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
