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.
span multiple controller/model/view triads to confirm the expected
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.
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.
@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.
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.
RSpec:
fields is submitted successfully, like 20 times? I’ll only simulate
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.