[rspec-users] Integrate or isolate views?

Zach Dennis zach.dennis at gmail.com
Wed Jul 1 13:14:11 EDT 2009


On Sun, Jun 28, 2009 at 10:32 AM, Jesse Crockett<lists at ruby-forum.com> wrote:
> Hello,
>
> 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?

Yes you can do this. Personally, I find it a benefit in discovery,
maintenance, and readability to have simple and focused focused view
and controller specs rather than a controller spec trying to do it
all. There is less of a barrier when writing an isolated view spec
then there is when writing a integrated 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.

Cucumber does a great job of providing a way to drive a lot of what's
in your views (especially forms). There are many times when Cucumber
is sufficient. However, there are plenty of times where your views
have details or a some view logic where it may not be covered with
your Cucumber scenarios or it may not be clear. In these cases a very
simple view spec can be a quick and effective way to drive your views.

In my opinion if view specs are hard to write and difficult to
maintain you're doing it wrong, either in what you're spec'ing or what
you're trying to implement. Writing view specs quickly and effectively
requires that you get into a groove for writing simple views that
drive methods into existence on other objects. Of course, finding that
groove may mean rethinking how you're writing views, and understanding
and knowing what rspec and webrat gives you. And this is one of the
major goals of the Rails Views chapter. To get you comfortable with
how to drive a view spec and understanding what the tools provide for
you. It does provides some insight into the what/when/why, but that's
not its major focus at this time, more of the focus is the how.

Based on my experience driving things from the views on down led to
more robust code. Even though it's a simple practice, I spent less
time revisiting controllers and models because the views defined what
was required before I even got there. It also forced me to think
outside the box and recognize the value of presenters. Presenters are
one thing not covered in the book, and I'm not sure how widespread
they are, but I for one find them simple and powerful tool in my
toolbox. If you're interested here's a link:
http://wiki.github.com/mhs/caching_presenter

Thank you for sharing your frustration about this. It seems to have
spurred a lot of good input, and hopefully the Rails Views chapter
will be able to be updated to tackle some of the challenges you found
as a reader,



>
> Please help.  thanks
>
> Jesse
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
Zach Dennis
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD training)
@zachdennis (twitter)


More information about the rspec-users mailing list