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? 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. Please help. thanks Jesse -- Posted via http://www.ruby-forum.com/.
On Jun 28, 2009, at 8:32 AM, Jesse Crockett 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?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. -Ben
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 Mabey wrote:> > On Jun 28, 2009, at 8:32 AM, Jesse Crockett 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? > > 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. > > -Ben > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-usershttp://www.ultrasaurus.com
Ben Mabey wrote:> On Jun 28, 2009, at 8:32 AM, Jesse Crockett wrote: > >> 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. > > -BenI 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? -- Posted via http://www.ruby-forum.com/.
Sarah Allen wrote:> 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 > > SarahIMO, 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 -- Posted via http://www.ruby-forum.com/.
Jesse Crockett wrote:> Ben Mabey wrote: > >> On Jun 28, 2009, at 8:32 AM, Jesse Crockett wrote: >> >> >>> 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? >Yes, IME this has worked well.> >> 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? >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. HTH, Ben
Jesse, I wrote a post that reflected on the pros/cons of testing views on a project of ours. http://simplechatter.com/2008/02/ascribe-a-case-study-on-view-specs/ 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 Crockett 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 Moazeni http://simplechatter.com
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. Pat On Sun, Jun 28, 2009 at 7: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? > > 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. > > 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 >
On Sun, Jun 28, 2009 at 11:56 AM, Sarah Allen<sarah at ultrasaurus.com> wrote:> 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+1 Pat
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)
On Wed, Jul 1, 2009 at 1:10 PM, Pat Maddox<pat.maddox at gmail.com> wrote:> On Sun, Jun 28, 2009 at 11:56 AM, Sarah Allen<sarah at ultrasaurus.com> wrote: >> 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 > > +1+1 as well. The last sentence here really nails it on the head for me,> > Pat > _______________________________________________ > 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)
On 1 Jul 2009, at 18:14, Zach Dennis wrote:> On Wed, Jul 1, 2009 at 1:10 PM, Pat Maddox<pat.maddox at gmail.com> > wrote: >> On Sun, Jun 28, 2009 at 11:56 AM, Sarah >> Allen<sarah at ultrasaurus.com> wrote: >>> 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 >> >> +1 > > +1 as well. The last sentence here really nails it on the head for me,It''s surprising what a wise guide an aversion to boredom can be. cheers, Matt Wynne http://mattwynne.net +447974 430184