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

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

On 4 Aug 2010, at 18:44, Lille 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
If your goal is to have a set of executable specs that the client can validate
by reading them, consider writing them in Cucumber but wiring them directly to
the models.

George Dinwiddie has blogged about this I think but I can''t find the
reference.

You can combine these with some other scenarios that focus on the behaviour of
the user interface if you feel you need that assurance.


> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
cheers,
Matt

http://blog.mattwynne.net
+44(0)7974 430184

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

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.

Thanks,

Lille

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

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 <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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

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 <dchelim... at gmail.com>
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 <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
> > _______________________________________________
> > 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

Matt, Lille,

On 8/4/10 2:58 PM, Matt Wynne wrote:
>
> On 4 Aug 2010, at 18:44, Lille 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
>
> If your goal is to have a set of executable specs that the client can
> validate by reading them, consider writing them in Cucumber but
> wiring them directly to the models.
Yes, I''m a big proponent of verifying business rules at the lowest
level
possible.  It''s easier to do so, and it also helps cover all the 
possibiities.
> George Dinwiddie has blogged about this I think but I can''t find
the
> reference.
I''ve certainly talked a lot on acceptance testing at multiple levels, 
but I don''t think I''ve blogged on it, yet.  I should remedy
that.
> You can combine these with some other scenarios that focus on the
> behaviour of the user interface if you feel you need that assurance.
Yes, you''ll probably always need at least one scenario to verify that 
things are wired up correctly.

  - George

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------