[rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat)

Lille lille.penguini at gmail.com
Wed Aug 4 15:48:02 EDT 2010

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.) 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.



On Aug 4, 3:06 pm, Tim Walker <walke... at gmail.com> 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 <lille.pengu... at gmail.com> 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
> > rspec-us... at rubyforge.org
> >http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list