I’ve been trying for two years to pick up BDD. I’m making progress,
have just read through the chapters in The RSpec Book on spec’ing views
and controllers.
What is the difference between using integrate_views and doing what
seems to be a lot of extra work to test the views in isolation?
When I use integrate_views, can I write view spec in what would
otherwise be isolated controller spec?
I read that I’m “encouraged” to do these in isolation, but IMHO the
chapter on spec’ing views is not very convincing in its own right, it
tells me that it’s good, but doesn’t show me as much, compared to the
examples and descriptions of circumstance that make several other
chapters very convincing.
When I use integrate_views, can I write view spec in what would
otherwise be isolated controller spec?
Correct, by default RSpec’s controller specs will not render the
view. This allows you to test the controller and view in complete
isolation. By turning on integrate_views you can specify what the
rendered view should contain at the same time. If you were to do
outside-in dev starting from the view you would start out by writing
an isolated view spec. That spec would say that such and such would
be displayed. This would in turn prompt you to assign something to
that view for it to be rendered. That is then your signal that the
controller needs to assign that object. So, you go up a level and
make sure that the controller action is assigning the needed object
for the view. That object will most likely have to answer to some
methods used in the view so that prompts you to start writing examples
on the model level. Isolation has it’s benefits, however an
integration test (i.e. Cucumber scenario) is really needed to make
sure these parts are all working together as expected.
I read that I’m “encouraged” to do these in isolation, but IMHO the
chapter on spec’ing views is not very convincing in its own right, it
tells me that it’s good, but doesn’t show me as much, compared to the
examples and descriptions of circumstance that make several other
chapters very convincing.
FWIW Jesse, you are not alone on this list in thinking that view specs
are not that valuable. A lot of people share your opinion, and I
think Cucumber is generally used to specify the views the majority of
the time. This enables you to specify your controllers in isolation
since your Cucumber features are cutting through the entire stack. I
personally think view specs are a very nice tool to have available,
but I would only use them on complex views. By complex I don’t mean
riddled with logic, but a view that has a lot of stuff going on which
is hard to set up all in one integration test (or Cucumber scenario).
Since the majority of views are very simple then verifying them just
in Cucumber is good enough, IMO.
When I use integrate_views, can I write view spec in what would
otherwise be isolated controller spec?
Correct, by default RSpec’s controller specs will not render the
view. This allows you to test the controller and view in complete
isolation. By turning on integrate_views you can specify what the
rendered view should contain at the same time. If you were to do
outside-in dev starting from the view you would start out by writing
an isolated view spec. That spec would say that such and such would
be displayed. This would in turn prompt you to assign something to
that view for it to be rendered. That is then your signal that the
controller needs to assign that object. So, you go up a level and
make sure that the controller action is assigning the needed object
for the view. That object will most likely have to answer to some
methods used in the view so that prompts you to start writing examples
on the model level. Isolation has it’s benefits, however an
integration test (i.e. Cucumber scenario) is really needed to make
sure these parts are all working together as expected.
I read that I’m “encouraged” to do these in isolation, but IMHO the
chapter on spec’ing views is not very convincing in its own right, it
tells me that it’s good, but doesn’t show me as much, compared to the
examples and descriptions of circumstance that make several other
chapters very convincing.
FWIW Jesse, you are not alone on this list in thinking that view specs
are not that valuable. A lot of people share your opinion, and I
think Cucumber is generally used to specify the views the majority of
the time. This enables you to specify your controllers in isolation
since your Cucumber features are cutting through the entire stack.
I gather that you are saying a balance of cucumber scenarios in tandem
with spec’ing controllers and models in isolation is a reasonable
conclusion and equally reasonable path to move forward?
I personally think view specs are a very nice tool to have available,
but I would only use them on complex views. By complex I don’t mean
riddled with logic, but a view that has a lot of stuff going on which
is hard to set up all in one integration test (or Cucumber scenario).
Since the majority of views are very simple then verifying them just
in Cucumber is good enough, IMO.
-Ben
I gather that you are affirming that adequate testing of controllers and
models in isolation as presscribed the the Rspec Book can be
accomplished without spec’ing the views in the same isolation, but
instead by using ‘integrate_views’ with adequate cucumber scenarios?
I find that testing views independently is useful just to catch HTML
errors that can sometime creep in during a re-factor. These check
important details that would be more tedious using cucumber. The
controller specs establish the post-condition for the controller
independent of the view. In the project I’m working on (which has
mobile clients as well as a website), we have end-to-end integrations
tests using cucumber that are primarily around our XML APIs (which are
from my perspective, just a different kind of view) – these also
serve as developer docs.
My $.02
Sarah
On Jun 28, 2009, at 10:27 AM, Ben M. wrote:
What is the difference between using integrate_views and doing what
an isolated view spec. That spec would say that such and such would
majority of the time. This enables you to specify your controllers
isolation. By turning on integrate_views you can specify what the
integration test (i.e. Cucumber scenario) is really needed to make
are not that valuable. A lot of people share your opinion, and I
think Cucumber is generally used to specify the views the majority of
the time. This enables you to specify your controllers in isolation
since your Cucumber features are cutting through the entire stack.
I gather that you are saying a balance of cucumber scenarios in tandem
with spec’ing controllers and models in isolation is a reasonable
conclusion and equally reasonable path to move forward?
Yes, IME this has worked well.
I gather that you are affirming that adequate testing of controllers and
models in isolation as presscribed the the Rspec Book can be
accomplished without spec’ing the views in the same isolation, but
instead by using ‘integrate_views’ with adequate cucumber scenarios?
The last part of your sentence is confusing me: “but instead by using
‘integrate_views’ with adequate cucumber scenarios?”. There is no
“integrate_views” option in Cucumber as views are always rendered. When
I am using Cucumber I don’t see the need to be using ‘integrate_views’
in my controller specs either.
Keep in mind that I’m not affirming anything as a hard rule, but rather
stating a guideline that I have gravitated towards in my past projects
that were webapps. You, like Sarah, may see enough value provided by
view specs to warrant them. I would encourage you to try them and then
judge for yourself and the specific project you are working on. If you
don’t get any value out of them then you can stop but you will at least
know how to do it when a situation arises that seems better fit for
them.
I find that testing views independently is useful just to catch HTML
errors that can sometime creep in during a re-factor. These check
important details that would be more tedious using cucumber. The
controller specs establish the post-condition for the controller
independent of the view. In the project I’m working on (which has
mobile clients as well as a website), we have end-to-end integrations
tests using cucumber that are primarily around our XML APIs (which are
from my perspective, just a different kind of view) – these also
serve as developer docs.
My $.02
Sarah
IMO, this is what the RSpec Book needs (at this point in beta),
real-world conclusions based on experience, rather than “take it on
faith that you will ‘revel’ in the rewards.” Thanks, Sarah
If your controllers are fat, test in isolation. For skinny
controllers I will sometimes forgo controller specs altogether and
implicitly verify the integration through cucumber features.
Sometimes there’s something funky that makes the cucumber failure
output difficult to interpret, and controller specs can make it easy
to pinpoint.
I don’t expect this to persuade anyone, but it was an attempt at an
objective perspective.
On Jun 28, 2009, at 3:16 PM, Jesse C. wrote:
IMO, this is what the RSpec Book needs (at this point in beta),
real-world conclusions based on experience, rather than “take it on
faith that you will ‘revel’ in the rewards.” Thanks, Sarah
–
Zach M.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.