Hello list, I have an example/spec that relates to the Product#index view and says "it should display only the active products". The thing is the logic to filter the active products should be in the model, and not on the view, since the view should be "dumb". I just realized that, and what I think is, even though this statement has business value, it is not lower level enough to be a view spec, nor a model or controller spec -- it should be a cucumber step, if any. Could someone enlighten-me, here? :) Thanks in advance, Marcelo.
On Mon, Jul 20, 2009 at 5:30 PM, Marcelo de Moraes Serpa<celoserpa at gmail.com> wrote:> Hello list, > > ?I have an example/spec that relates to the Product#index view and > says "it should display only the active products". The thing is the > logic to filter the active products should be in the model, and not on > the view, since the view should be "dumb". I just realized that, and > what I think is, even though this statement has business value, it is > not lower level enough to be a view spec, nor a model or controller > spec -- it should be a cucumber step, if any. > > Could someone enlighten-me, here? :)Hi Marcelo, This is a point of confusion for many, so you''re not alone. I''ll offer my take, though I know there are others who see it differently. I use Cucumber for specifying application behaviour and RSpec for specifying lower level component behaviour. In the scenario you describe: * the application''s job is to show only the active products * the view''s job is to display any products it is given by the controller * the controller''s job is to ask the model for the active products * the model''s job is to supply only the active products So for me this is not an either/or question. Each underlying component has a responsibility, and the result of the three components doing the right thing adds up to the application behaving correctly. Now, it happens that the outcomes we expect from the application are the same outcomes we expect from the view. Many see this as duplication, and if you agree with them, then you still may want a cucumber scenario + a controller spec + a model spec. For me, even though they appear to be overlapping, they are not. The outcomes are the same, but the inputs are different. The scenario says the application has to show x given some inputs. The view spec says the view has to show x given some data supplied by the controller. Different behaviour. Now the last question I''d ask myself is whether the duplication in the expected outcomes in the scenario and the view spec buys me anything, and that really depends on how complex the view is, and whether I anticipate doing much refactoring with it (moving partials around, etc). One approach would be to err on the side of less overhead, but then when I do go to refactor, make sure there are relevant view specs in place before I do. HTH, David> > Thanks in advance, > > Marcelo. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Marcelo, My take on this is that if your business user wants to make sure that there are only active products displayed, then it should be in a story. There may be a question about speccing the implementation; however if you are using a named scope - you might argue that you are testing a library (and thus, you shouldn''t bother, as the library should test itself.) I would consider a simple spec for named scope to prove that it works. With the named scope tested you can mention it incidentally in your story and not get too hung up on the exact details. I''ve just noticed I''ve been writing this draft for so long, David C has also answered, I am as interested as you to read that, so HTH. -- Lee Hambley Twitter: @leehambley Blog: http://lee.hambley.name/ Working with Rails: http://is.gd/1s5W1 2009/7/20 Marcelo de Moraes Serpa <celoserpa at gmail.com>> Hello list, > > I have an example/spec that relates to the Product#index view and > says "it should display only the active products". The thing is the > logic to filter the active products should be in the model, and not on > the view, since the view should be "dumb". I just realized that, and > what I think is, even though this statement has business value, it is > not lower level enough to be a view spec, nor a model or controller > spec -- it should be a cucumber step, if any. > > Could someone enlighten-me, here? :) > > Thanks in advance, > > Marcelo. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090721/621a6f47/attachment.html>
On Mon, Jul 20, 2009 at 5:58 PM, David Chelimsky<dchelimsky at gmail.com> wrote:> On Mon, Jul 20, 2009 at 5:30 PM, Marcelo de Moraes > Serpa<celoserpa at gmail.com> wrote: >> Hello list, >> >> ?I have an example/spec that relates to the Product#index view and >> says "it should display only the active products". The thing is the >> logic to filter the active products should be in the model, and not on >> the view, since the view should be "dumb". I just realized that, and >> what I think is, even though this statement has business value, it is >> not lower level enough to be a view spec, nor a model or controller >> spec -- it should be a cucumber step, if any. >> >> Could someone enlighten-me, here? :) > > Hi Marcelo, > > This is a point of confusion for many, so you''re not alone. I''ll offer > my take, though I know there are others who see it differently. > > I use Cucumber for specifying application behaviour and RSpec for > specifying lower level component behaviour. In the scenario you > describe: > * the application''s job is to show only the active products > * the view''s job is to display any products it is given by the controller > * the controller''s job is to ask the model for the active products > * the model''s job is to supply only the active products > > So for me this is not an either/or question. Each underlying component > has a responsibility, and the result of the three components doing the > right thing adds up to the application behaving correctly. > > Now, it happens that the outcomes we expect from the application are > the same outcomes we expect from the view. Many see this as > duplication, and if you agree with them, then you still may want a > cucumber scenario + a controller spec + a model spec. > > For me, even though they appear to be overlapping, they are not. The > outcomes are the same, but the inputs are different. The scenario says > the application has to show x given some inputs. The view spec says > the view has to show x given some data supplied by the controller. > Different behaviour. > > Now the last question I''d ask myself is whether the duplication in the > expected outcomes in the scenario and the view spec buys me anything, > and that really depends on how complex the view is, and whether I > anticipate doing much refactoring with it (moving partials around, > etc). One approach would be to err on the side of less overhead, but > then when I do go to refactor, make sure there are relevant view specs > in place before I do.Afterthought (or two): You asked about cucumber scenario vs model spec and I responded from a wider viewpoint. I think the same thinking applies to the scenario and the model, though in that case, the expected outcomes are actually different (application renders stuff on a page, model returns the right collection). This is actually a perfect example of when it''s good to have view specs because the view template is probably the same view template whether the app is displaying active products, inactive products, or products that shipped last Tuesday. If the view fails to do its job, three scenarios will fail. Perhaps they''ll fail in such a way that you can quickly isolate the point of failure. Or, perhaps you''ll not be sure whether the problem lies in the view, the controller, or the model. In this case, being able to see passing specs for the view would help point you to the other components. Food for thought. Cheers, David> > HTH, > David > > > > > >> >> Thanks in advance, >> >> Marcelo. >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> >
On Jul 20, 2009, at 6:58 PM, David Chelimsky wrote:> So for me this is not an either/or question. Each underlying component > has a responsibility, and the result of the three components doing the > right thing adds up to the application behaving correctly.I''d also add that, for me, the cucumber story tends to exercise the more "typical" cases whereas my specs are more thorough in covering edge cases and exceptions. linoj
Thank you all for the replies!>I use Cucumber for specifying application behaviour and RSpec for >specifying lower level component behaviour. In the scenario you >describe: >* the application''s job is to show only the active products >* the view''s job is to display any products it is given by the controller >* the controller''s job is to ask the model for the active products >* the model''s job is to supply only the active productsThis was the most useful piece of information I''ve seen lately. I think I was still not thinking with this behaviour mindset, and asking this question -- "what is the responsibility/job of the controller in this context" really helped me to find out that the controller''s job is to ask the model for the data, and this is exactly what I need to spec -- if he is sending the right message and setting the right variables. By the way, great work on the rspec book, it has been really helping me to master the art of BDD, along with your tireless support here in the mailing list. Thanks a lot for the support! Regards, Marcelo. On Mon, Jul 20, 2009 at 9:54 PM, Jonathan Linowes<jonathan at parkerhill.com> wrote:> > On Jul 20, 2009, at 6:58 PM, David Chelimsky wrote: > >> So for me this is not an either/or question. Each underlying component >> has a responsibility, and the result of the three components doing the >> right thing adds up to the application behaving correctly. > > I''d also add that, for me, the cucumber story tends to exercise the more > "typical" cases whereas my specs are more thorough in covering edge cases > and exceptions. > > linoj > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >