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

Tim Walker walketim at gmail.com
Wed Aug 4 15:06:36 EDT 2010

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.


On Wed, Aug 4, 2010 at 11:44 AM, Lille <lille.penguini 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-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list