[rspec-users] [newbie] tradeoffs of direct model access vs. simulated browser (webrat)
dchelimsky at gmail.com
Wed Aug 4 17:01:06 EDT 2010
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.
> 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
>> from the UI through to the data persistence.
>> On Wed, Aug 4, 2010 at 11:44 AM, Lille <lille.pengu... at gmail.com> wrote:
>>> 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
>>> + 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
>>> 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.
>>> rspec-users mailing list
>>> rspec-us... at rubyforge.org
>> rspec-users mailing list
>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users