On Sun, Jun 28, 2009 at 10:32 AM, Jesse Crockett<li...@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@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) _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
