David, Thank you for your kind attention. Yes, I have reviewed the referenced portions of The RSpec Book and see that my interpretation of an opposition bewteen the simulated browser and direct model approaches -- from within cucumber -- was exaggerated. I am glad that you approve of my other reasoning, regardless, and that I found my way to it -- however indirectly -- by reference to your book.
I think with all the balls up in the air, I failed to catch that scenarios dwell in features and do not illustrate use cases in the way I have meant it: as navigation through multiple controller/model/view groups to reach a result, e.g., 'purchase', 'loan amount', etc. From now on, when I think of cases where results must be true depending on certain inputs, I will think immediately of cucumber without simulating the browser. Thanks, Lille On Aug 4, 5:01 pm, David Chelimsky <[email protected]> wrote: > On Aug 4, 2010, at 2:48 PM, Lille wrote: > > > I appreciate your comments... > > > @Matt - sounds like you're reminding me I can have a unified > > presentation to the customer if I express all my specs in cucumber, > > whether any individual scenario takes the simulated browser approach > > or not. > > > I'm basing my freshman efforts here on 'The RSpec Book', whose beta > > version suggests that one might BDD their views/models/controllers > > each in isolation if they hadn't already decided on taking a simulated > > browser approach with webrat (+ selenium.) > > There is a brief discussion in the views chapter that says that the jury is > out on the value of view specs in some contexts and tries to put some > guidelines into place about how to approach a decision about doing them or > not. But that is only for view specs and it is context specific. It does not > apply to controller and model specs, and is not intended to suggest that > cukes vs specs is an either/or proposition. > > There is a picture on the 3rd page of the Rails section of the book that very > clearly conveys the process: start with cukes and use them to drive down to > view, controller and model specs. > > > I guess I don't think this > > choice -- as I interpret it from "The RSpec Book' -- is arbitrary: in > > my case, upon consideration, simulating the browser in every scenario > > doesn't seem the best approach. > > The DMA vs Simulated Browser decision is discussed in several places in the > first few chapters of the Rails section as well. There is a section in the > Cucumber with Rails chapter that states: "For features that produce many edge > cases, it can be useful to drive a few through the Rails stack and the rest > using just Direct Model Access for everything." > > Seems like your conclusion is perfectly aligned with the book's > recommendations. > > Cheers, > David > > > > > Thanks, > > > Lille > > > On Aug 4, 3:06 pm, Tim Walker <[email protected]> wrote: > >> We constantly explore and define this delicate balance. It's not easy > >> and there are no absolutes! > > >> One thing that drives us is to approach the "automated testing stack" > >> as a pyramid (not sure where this originates but we used a slide of it > >> when we used to teach executable requirements with fitnesse). The > >> base, widest slice, of the pyramid is your unit tests which you should > >> have the most of. Moving up to controller tests and cucumber tests > >> (not through the user interface). What's left is the smallest piece, > >> the UI tests, which should focus on the UI, probably. Probably because > >> we're constantly breaking the rules. On complex pages with a lot of > >> javascript and xhr callbacks it's important to test the entire stack > >> from the UI through to the data persistence. > > >> Tim > > >> On Wed, Aug 4, 2010 at 11:44 AM, Lille <[email protected]> wrote: > >>> Hi, > > >>> My app involves the elicitation of tabular data over a succession of > >>> controller/model/view groups. The net result is a numeric outcome > >>> based on the entered data (basically, it's a spreadsheet on Rails.) > > >>> Here is the nub of my question about developing such a thing with > >>> RSpec: > > >>> + if I test with a simulated browser approach, my scenarios will need > >>> span multiple controller/model/view triads to confirm the expected > >>> result in as many cases as I feel I need to cover. Basically, an > >>> entire app use-cycle is contained in every scenario -- this doesn't > >>> remind me of anything I've seen in "The RSpec Book", for example. > > >>> + I think I prefer rspec'ing the models directly -- it's concise and I > >>> don't duplicate simulated browser actions for no particular reason. > >>> What's the point of confirming that different data in the same set of > >>> fields is submitted successfully, like 20 times? I'll only simulate > >>> the browser to build the view/controllers and test their behavior when > >>> inputs are inadequate or require differential responses. > > >>> My preferred strategy is sort of like saying to the client: 1) here > >>> are all the numeric outcomes we need to confirm, and 2) here in a > >>> smaller, overlapping set are the behavioral outcomes we need to > >>> confirm > > >>> In short, it seems to me the simulated browser approach (webrat) is > >>> overkill when one is dealing with exhaustive cases and there is no > >>> differential response in the controller or view parts based on them. > > >>> Lille > >>> _______________________________________________ > >>> rspec-users mailing list > >>> [email protected] > >>>http://rubyforge.org/mailman/listinfo/rspec-users > > >> _______________________________________________ > >> rspec-users mailing list > >> [email protected]http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > > rspec-users mailing list > > [email protected] > >http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > [email protected]http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
