Hey, we''re currently using shoulda (http://dev.thoughtbot.com/ shoulda/) on a project and I saw some things that would be really nice to see in rspec, namely the should_ methods, and especially the should_be_restful method. Do these go against the rspec goals at all? Or could an ambitious programmer go to town implementing these for rspec_on_rails? Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2
On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote:> Hey, we''re currently using shoulda (http://dev.thoughtbot.com/ > shoulda/) on a project and I saw some things that would be really nice > to see in rspec, namely the should_ methods, and especially the > should_be_restful method. Do these go against the rspec goals at > all? Or could an ambitious programmer go to town implementing these > for rspec_on_rails?The current philosophy is to keep these kinds of things as plugins. A few of us have started to extract common matchers into a plugin which can be found at http://code.google.com/p/rspec-on-rails-matchers/. Feel free to submit a patch if we''re missing something that you''d like. -- Josh Knowles phone: 509-979-1593 email: joshknowles at gmail.com web: http://joshknowles.com
Hmm, that includes a good number of them, but there''s still the restful resource to think about, which is in my opinion the most valuable one. Would you consider the addition of a restful resource matcher similar to shoulda''s? Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 5:40 PM, Josh Knowles wrote:> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: >> Hey, we''re currently using shoulda (http://dev.thoughtbot.com/ >> shoulda/) on a project and I saw some things that would be really >> nice >> to see in rspec, namely the should_ methods, and especially the >> should_be_restful method. Do these go against the rspec goals at >> all? Or could an ambitious programmer go to town implementing these >> for rspec_on_rails? > > The current philosophy is to keep these kinds of things as plugins. A > few of us have started to extract common matchers into a plugin which > can be found at http://code.google.com/p/rspec-on-rails-matchers/. > Feel free to submit a patch if we''re missing something that you''d > like. > > > -- > Josh Knowles > phone: 509-979-1593 > email: joshknowles at gmail.com > web: http://joshknowles.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote:> Hmm, that includes a good number of them, but there''s still the > restful resource to think about, which is in my opinion the most > valuable one. Would you consider the addition of a restful resource > matcher similar to shoulda''s?Yes. If you work something up I''d happily add it. Unfortunately I don''t have the need/time/desire to do it myself right now though. -- Josh Knowles phone: 509-979-1593 email: joshknowles at gmail.com web: http://joshknowles.com
We''ll see if I get around to it. It would be a lot of work, I think, and I know a couple people who have started similar efforts. Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 5:47 PM, Josh Knowles wrote:> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: >> Hmm, that includes a good number of them, but there''s still the >> restful resource to think about, which is in my opinion the most >> valuable one. Would you consider the addition of a restful resource >> matcher similar to shoulda''s? > > Yes. If you work something up I''d happily add it. Unfortunately I > don''t have the need/time/desire to do it myself right now though. > > -- > Josh Knowles > phone: 509-979-1593 > email: joshknowles at gmail.com > web: http://joshknowles.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Also, that strikes me as strange that the current philosophy is that for the rspec_on_rails plugin. I would think rails-specific matchers would be endorsed at some point, since rails is so big on convention. Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 5:40 PM, Josh Knowles wrote:> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: >> Hey, we''re currently using shoulda (http://dev.thoughtbot.com/ >> shoulda/) on a project and I saw some things that would be really >> nice >> to see in rspec, namely the should_ methods, and especially the >> should_be_restful method. Do these go against the rspec goals at >> all? Or could an ambitious programmer go to town implementing these >> for rspec_on_rails? > > The current philosophy is to keep these kinds of things as plugins. A > few of us have started to extract common matchers into a plugin which > can be found at http://code.google.com/p/rspec-on-rails-matchers/. > Feel free to submit a patch if we''re missing something that you''d > like. > > > -- > Josh Knowles > phone: 509-979-1593 > email: joshknowles at gmail.com > web: http://joshknowles.com > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Jan 10, 2008 5:50 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:> Also, that strikes me as strange that the current philosophy is that > for the rspec_on_rails plugin. I would think rails-specific matchers > would be endorsed at some point, since rails is so big on convention.It''s actually quite sane. I''ll give you an example: have_tag. That was initially implemented completely within RSpec. Rails was a moving target so it kept breaking. So we changed it to rely on assert_select, which ships w/ rails. It''s been very stable since, but assert_select has not been updated with the new features - especially in terms of rjs, so it is no longer complete. What I''d really like to see now is that have_tag gets implemented w/ hpricot, but doing so would risk breaking a lot of existing specs. With a plugin approach, there is no problem. The community can offer different solutions to different problem sets. Another issue is BDD philosophy. BDD is about behaviour. should have_many(:posts) is not behaviour. It is structure. I understand that there are people who view this differently, and I would not want to get in the way of anyone using that approach, but RSpec should not be sporting conveniences, even very pragmatic ones, that fundamentally go against the grain of BDD. FWIW, David> > Nathan Sutton > fowlduck at gmail.com > rspec 1.1 > rspec_on_rails 1.1 > rails 2.0.2 > > On Jan 10, 2008, at 5:40 PM, Josh Knowles wrote: > > > > On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: > >> Hey, we''re currently using shoulda (http://dev.thoughtbot.com/ > >> shoulda/) on a project and I saw some things that would be really > >> nice > >> to see in rspec, namely the should_ methods, and especially the > >> should_be_restful method. Do these go against the rspec goals at > >> all? Or could an ambitious programmer go to town implementing these > >> for rspec_on_rails? > > > > The current philosophy is to keep these kinds of things as plugins. A > > few of us have started to extract common matchers into a plugin which > > can be found at http://code.google.com/p/rspec-on-rails-matchers/. > > Feel free to submit a patch if we''re missing something that you''d > > like. > > > > > > -- > > Josh Knowles > > phone: 509-979-1593 > > email: joshknowles at gmail.com > > web: http://joshknowles.com > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
There David goes, making sense again. Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 5:59 PM, David Chelimsky wrote:> On Jan 10, 2008 5:50 PM, Nathan Sutton <nathan.sutton at gmail.com> > wrote: >> Also, that strikes me as strange that the current philosophy is that >> for the rspec_on_rails plugin. I would think rails-specific matchers >> would be endorsed at some point, since rails is so big on convention. > > It''s actually quite sane. I''ll give you an example: have_tag. That was > initially implemented completely within RSpec. Rails was a moving > target so it kept breaking. So we changed it to rely on assert_select, > which ships w/ rails. It''s been very stable since, but assert_select > has not been updated with the new features - especially in terms of > rjs, so it is no longer complete. > > What I''d really like to see now is that have_tag gets implemented w/ > hpricot, but doing so would risk breaking a lot of existing specs. > > With a plugin approach, there is no problem. The community can offer > different solutions to different problem sets. > > Another issue is BDD philosophy. BDD is about behaviour. should > have_many(:posts) is not behaviour. It is structure. I understand that > there are people who view this differently, and I would not want to > get in the way of anyone using that approach, but RSpec should not be > sporting conveniences, even very pragmatic ones, that fundamentally go > against the grain of BDD. > > FWIW, > David > >> >> Nathan Sutton >> fowlduck at gmail.com >> rspec 1.1 >> rspec_on_rails 1.1 >> rails 2.0.2 >> >> On Jan 10, 2008, at 5:40 PM, Josh Knowles wrote: >> >> >>> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: >>>> Hey, we''re currently using shoulda (http://dev.thoughtbot.com/ >>>> shoulda/) on a project and I saw some things that would be really >>>> nice >>>> to see in rspec, namely the should_ methods, and especially the >>>> should_be_restful method. Do these go against the rspec goals at >>>> all? Or could an ambitious programmer go to town implementing >>>> these >>>> for rspec_on_rails? >>> >>> The current philosophy is to keep these kinds of things as >>> plugins. A >>> few of us have started to extract common matchers into a plugin >>> which >>> can be found at http://code.google.com/p/rspec-on-rails-matchers/. >>> Feel free to submit a patch if we''re missing something that you''d >>> like. >>> >>> >>> -- >>> Josh Knowles >>> phone: 509-979-1593 >>> email: joshknowles at gmail.com >>> web: http://joshknowles.com >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Jan 10, 2008 6:02 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:> Nathan Sutton > fowlduck at gmail.com > rspec 1.1 > rspec_on_rails 1.1 > rails 2.0.2I love that your sig has your rspec and rails versions. That cracks me up.
On Thu, 2008-01-10 at 17:59 -0600, David Chelimsky wrote:> Another issue is BDD philosophy. BDD is about behaviour. should > have_many(:posts) is not behaviour. It is structure. I understand that > there are people who view this differently, and I would not want to > get in the way of anyone using that approach, but RSpec should not be > sporting conveniences, even very pragmatic ones, that fundamentally go > against the grain of BDD.Out of interest, how would/do you test associations David? What if should have_many(:posts) tested the behaviour of the association rather than whether it''s defined? -- Jonathan Leighton http://jonathanleighton.com/
Speaking for myself, since I support the same philosophy, I wouldn''t test the association. I don''t care that it has_many posts. I might care that I can add multiple posts, or that I can find posts by criteria, so I would test that. JD On Jan 10, 2008, at 4:04 PM, Jonathan Leighton wrote:> On Thu, 2008-01-10 at 17:59 -0600, David Chelimsky wrote: >> Another issue is BDD philosophy. BDD is about behaviour. should >> have_many(:posts) is not behaviour. It is structure. I understand >> that >> there are people who view this differently, and I would not want to >> get in the way of anyone using that approach, but RSpec should not be >> sporting conveniences, even very pragmatic ones, that fundamentally >> go >> against the grain of BDD. > > Out of interest, how would/do you test associations David? What if > should have_many(:posts) tested the behaviour of the association > rather > than whether it''s defined? > > -- > Jonathan Leighton > http://jonathanleighton.com/ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Hey now! Really though, have you ever been digging through old mailing lists and wondered which version they were using when they had that issue? Or when someone posts and issue, you need to ask them what versions of everything they''re using? It can be a pain and it usually wastes time/energy, so this is a simple solution. :) Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 6:04 PM, David Chelimsky wrote:> On Jan 10, 2008 6:02 PM, Nathan Sutton <nathan.sutton at gmail.com> > wrote: >> Nathan Sutton >> fowlduck at gmail.com >> rspec 1.1 >> rspec_on_rails 1.1 >> rails 2.0.2 > > I love that your sig has your rspec and rails versions. That cracks > me up. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Jan 10, 2008 6:04 PM, Jonathan Leighton <j at jonathanleighton.com> wrote:> On Thu, 2008-01-10 at 17:59 -0600, David Chelimsky wrote: > > Another issue is BDD philosophy. BDD is about behaviour. should > > have_many(:posts) is not behaviour. It is structure. I understand that > > there are people who view this differently, and I would not want to > > get in the way of anyone using that approach, but RSpec should not be > > sporting conveniences, even very pragmatic ones, that fundamentally go > > against the grain of BDD. > > Out of interest, how would/do you test associations David? What if > should have_many(:posts) tested the behaviour of the association rather > than whether it''s defined?It has more to do with what I''m looking at in my specs than what lies under the hood. Why do I care if a visitor has_many(:posts)? Maybe there is something different about a blogger with no posts vs one with 50. So I''d have an example: describe Blogger, "with no posts" do it "should be completely lame and banned for eternity" do @blogger.should be_completely_lame_and_banned_for_eternity end end describe Blogger, "with 1000 posts" do it "should be revered by the community" do (1..1000).each { @blogger.post(:title => "today''s thoughts") } @blogger.should be_revered_by_the_community end end Now we''re talking about behaviour. has_many is implied. No need to spec it directly - serves no purpose by itself. That all make sense?
On Jan 10, 2008 6:07 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:> Hey now! Really though, have you ever been digging through old > mailing lists and wondered which version they were using when they had > that issue? Or when someone posts and issue, you need to ask them > what versions of everything they''re using? It can be a pain and it > usually wastes time/energy, so this is a simple solution. :)I wasn''t criticizing. It cracks me up in the sort of "that''s so obvious, I should do it myself'' sort of way.> > Nathan Sutton > fowlduck at gmail.com > rspec 1.1 > rspec_on_rails 1.1 > rails 2.0.2 > > > On Jan 10, 2008, at 6:04 PM, David Chelimsky wrote: > > > On Jan 10, 2008 6:02 PM, Nathan Sutton <nathan.sutton at gmail.com> > > wrote: > >> Nathan Sutton > >> fowlduck at gmail.com > >> rspec 1.1 > >> rspec_on_rails 1.1 > >> rails 2.0.2 > > > > I love that your sig has your rspec and rails versions. That cracks > > me up. > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Well then, hop to! ;) Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 6:10 PM, David Chelimsky wrote:> On Jan 10, 2008 6:07 PM, Nathan Sutton <nathan.sutton at gmail.com> > wrote: >> Hey now! Really though, have you ever been digging through old >> mailing lists and wondered which version they were using when they >> had >> that issue? Or when someone posts and issue, you need to ask them >> what versions of everything they''re using? It can be a pain and it >> usually wastes time/energy, so this is a simple solution. :) > > I wasn''t criticizing. It cracks me up in the sort of "that''s so > obvious, I should do it myself'' sort of way. > >> >> Nathan Sutton >> fowlduck at gmail.com >> rspec 1.1 >> rspec_on_rails 1.1 >> rails 2.0.2 >> >> >> On Jan 10, 2008, at 6:04 PM, David Chelimsky wrote: >> >>> On Jan 10, 2008 6:02 PM, Nathan Sutton <nathan.sutton at gmail.com> >>> wrote: >>>> Nathan Sutton >>>> fowlduck at gmail.com >>>> rspec 1.1 >>>> rspec_on_rails 1.1 >>>> rails 2.0.2 >>> >>> I love that your sig has your rspec and rails versions. That cracks >>> me up. >> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Jan 10, 2008, at 4:11 PM, Nathan Sutton wrote:> Well then, hop to! ;) > Nathan Sutton > fowlduck at gmail.com > rspec 1.1 > rspec_on_rails 1.1 > rails 2.0.2 > > On Jan 10, 2008, at 6:10 PM, David Chelimsky wrote: > >> On Jan 10, 2008 6:07 PM, Nathan Sutton <nathan.sutton at gmail.com> >> wrote: >>> Hey now! Really though, have you ever been digging through old >>> mailing lists and wondered which version they were using when they >>> had >>> that issue? Or when someone posts and issue, you need to ask them >>> what versions of everything they''re using? It can be a pain and it >>> usually wastes time/energy, so this is a simple solution. :) >> >> I wasn''t criticizing. It cracks me up in the sort of "that''s so >> obvious, I should do it myself'' sort of way. >> >>> >>> Nathan Sutton >>> fowlduck at gmail.com >>> rspec 1.1 >>> rspec_on_rails 1.1 >>> rails 2.0.2 >>> >>> >>> On Jan 10, 2008, at 6:04 PM, David Chelimsky wrote: >>> >>>> On Jan 10, 2008 6:02 PM, Nathan Sutton <nathan.sutton at gmail.com> >>>> wrote: >>>>> Nathan Sutton >>>>> fowlduck at gmail.com >>>>> rspec 1.1 >>>>> rspec_on_rails 1.1 >>>>> rails 2.0.2 >>>> >>>> I love that your sig has your rspec and rails versions. That cracks >>>> me up. >>> >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-usersHop! James Deville http://devillecompanies.org james.deville at gmail.com rspec r3172 rspec_on_rails r3172 rails r8331
On Thu, 2008-01-10 at 18:09 -0600, David Chelimsky wrote:> It has more to do with what I''m looking at in my specs than what lies > under the hood. Why do I care if a visitor has_many(:posts)? Maybe > there is something different about a blogger with no posts vs one with > 50. So I''d have an example: > > describe Blogger, "with no posts" do > it "should be completely lame and banned for eternity" do > @blogger.should be_completely_lame_and_banned_for_eternity > end > end > > describe Blogger, "with 1000 posts" do > it "should be revered by the community" do > (1..1000).each { @blogger.post(:title => "today''s thoughts") } > @blogger.should be_revered_by_the_community > end > end > > Now we''re talking about behaviour. has_many is implied. No need to > spec it directly - serves no purpose by itself. > > That all make sense?In principle, yes. But what if your association isn''t that interesting. What if it is literally has_many :posts and that''s it. You still want to make sure it will work (for instance that the posts.blogger_id column actually exists), but you''ve got nothing interesting to poke it with... On the other hand maybe it''s stupid testing that as you are really testing the database, which is a different layer entirely. But in practise I know it''s quite usual to make a database change and inadvertently break an association you had forgotten about... Jon -- Jonathan Leighton http://jonathanleighton.com/
On Thu, 2008-01-10 at 18:47 -0500, Josh Knowles wrote:> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: > > Hmm, that includes a good number of them, but there''s still the > > restful resource to think about, which is in my opinion the most > > valuable one. Would you consider the addition of a restful resource > > matcher similar to shoulda''s? > > Yes. If you work something up I''d happily add it. Unfortunately I > don''t have the need/time/desire to do it myself right now though.My reservation with the idea of "should be restful" is that you have to assume an awful lot about how the controller is implemented. That''s fine if you use scaffolding excessively but if you actually write your own code (!!) things quickly start to deviate from the trodden path. Recently I have been writing my controller specs a bit like this (I have some support code to enable it): describe PostsController do controller_name :posts stub_resource describe "when a post is viewed and the current user is an admin" do log_in :as => :admin get :show, :id => 42 it_should_find it_should_load_awesome_admin_stuff end describe "when a post is edited by a normal user" do log_in :as => :prole get :edit, :id => 23 it_should_find it_should_warn it_should_redirect_to "the post''s page", :at => "post_path(@post)" end end Some of the above is me using my creative license but you get the idea. Just thought it might spark some ideas/opinions... it''s certainly not a perfect implementation/API but I''ve found the general idea quite useful. I personally think this is the right level at which to make the abstraction - you are still specifying the behaviour explicitly, just writing less code when doing it. Jon -- Jonathan Leighton http://jonathanleighton.com/
On Jan 10, 2008 4:17 PM, Jonathan Leighton <j at jonathanleighton.com> wrote:> In principle, yes. But what if your association isn''t that interesting. > What if it is literally has_many :posts and that''s it. You still want to > make sure it will work (for instance that the posts.blogger_id column > actually exists), but you''ve got nothing interesting to poke it with...I don''t know. I''m starting to think that this falls under the category of so simple it''s maybe not worth testing. Using Rails associations in the simplest way, i.e. no special conditions, is so declarative that I might consider it to be specification enough. I''m not sure though. I''m not totally cool with the idea of trashing the specs because the code is so expressive that it doesn''t need them. There''s always *something* interesting. If there weren''t, it wouldn''t be in the code to begin with, right? Your example can be something as simple as describe Blogger, " who just set up his site" do it "should have no posts" do Blogger.new.should have(0).posts end end That at least tells you that there''s a method named #posts, which responds to length, and has a length of 0 when the blogger is first instantiated. That''s more behavior-y than specifying the exact structure of it. I admit it''s not interesting in the "call the sheriff, pa, there''s somethin in the barn" sense, but it is interesting in that it''s a facet of behavior that''s worth knowing. Pat
You should browse over how shoulda does it here: http://thoughtbot.com/projects/shoulda/tutorial/controllers and here: http://dev.thoughtbot.com/shoulda/classes/ThoughtBot/Shoulda/Controller/ClassMethods.html Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 6:29 PM, Jonathan Leighton wrote:> On Thu, 2008-01-10 at 18:47 -0500, Josh Knowles wrote: >> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: >>> Hmm, that includes a good number of them, but there''s still the >>> restful resource to think about, which is in my opinion the most >>> valuable one. Would you consider the addition of a restful resource >>> matcher similar to shoulda''s? >> >> Yes. If you work something up I''d happily add it. Unfortunately I >> don''t have the need/time/desire to do it myself right now though. > > My reservation with the idea of "should be restful" is that you have > to > assume an awful lot about how the controller is implemented. That''s > fine > if you use scaffolding excessively but if you actually write your own > code (!!) things quickly start to deviate from the trodden path. > > Recently I have been writing my controller specs a bit like this (I > have > some support code to enable it): > > describe PostsController do > controller_name :posts > stub_resource > > describe "when a post is viewed and the current user is an admin" do > log_in :as => :admin > get :show, :id => 42 > > it_should_find > it_should_load_awesome_admin_stuff > end > > describe "when a post is edited by a normal user" do > log_in :as => :prole > get :edit, :id => 23 > > it_should_find > it_should_warn > it_should_redirect_to "the post''s page", :at => "post_path(@post)" > end > end > > Some of the above is me using my creative license but you get the > idea. > Just thought it might spark some ideas/opinions... it''s certainly > not a > perfect implementation/API but I''ve found the general idea quite > useful. > I personally think this is the right level at which to make the > abstraction - you are still specifying the behaviour explicitly, just > writing less code when doing it. > > Jon > > -- > Jonathan Leighton > http://jonathanleighton.com/ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
On Jan 10, 2008 6:48 PM, Nathan Sutton <nathan.sutton at gmail.com> wrote:> You should browse over how shoulda does it here: > http://thoughtbot.com/projects/shoulda/tutorial/controllersOr how others are supplying plugins for rspec: http://weblog.techno-weenie.net/2007/12/26/controller-specs-are-a-drag http://git.caboo.se/?p=altered_beast.git;a=tree;f=vendor/plugins/rspec_on_rails_on_crack/lib;h=62b5fe1ccad8186a989f5d72dd218f3678fae518;hb=HEAD> > and here: > http://dev.thoughtbot.com/shoulda/classes/ThoughtBot/Shoulda/Controller/ClassMethods.html > > Nathan Sutton > fowlduck at gmail.com > rspec 1.1 > rspec_on_rails 1.1 > rails 2.0.2 > > > On Jan 10, 2008, at 6:29 PM, Jonathan Leighton wrote: > > > On Thu, 2008-01-10 at 18:47 -0500, Josh Knowles wrote: > >> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: > >>> Hmm, that includes a good number of them, but there''s still the > >>> restful resource to think about, which is in my opinion the most > >>> valuable one. Would you consider the addition of a restful resource > >>> matcher similar to shoulda''s? > >> > >> Yes. If you work something up I''d happily add it. Unfortunately I > >> don''t have the need/time/desire to do it myself right now though. > > > > My reservation with the idea of "should be restful" is that you have > > to > > assume an awful lot about how the controller is implemented. That''s > > fine > > if you use scaffolding excessively but if you actually write your own > > code (!!) things quickly start to deviate from the trodden path. > > > > Recently I have been writing my controller specs a bit like this (I > > have > > some support code to enable it): > > > > describe PostsController do > > controller_name :posts > > stub_resource > > > > describe "when a post is viewed and the current user is an admin" do > > log_in :as => :admin > > get :show, :id => 42 > > > > it_should_find > > it_should_load_awesome_admin_stuff > > end > > > > describe "when a post is edited by a normal user" do > > log_in :as => :prole > > get :edit, :id => 23 > > > > it_should_find > > it_should_warn > > it_should_redirect_to "the post''s page", :at => "post_path(@post)" > > end > > end > > > > Some of the above is me using my creative license but you get the > > idea. > > Just thought it might spark some ideas/opinions... it''s certainly > > not a > > perfect implementation/API but I''ve found the general idea quite > > useful. > > I personally think this is the right level at which to make the > > abstraction - you are still specifying the behaviour explicitly, just > > writing less code when doing it. > > > > Jon > > > > -- > > Jonathan Leighton > > http://jonathanleighton.com/ > > > > _______________________________________________ > > rspec-users mailing list > > rspec-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
That too :) Nathan Sutton fowlduck at gmail.com rspec 1.1 rspec_on_rails 1.1 rails 2.0.2 On Jan 10, 2008, at 6:59 PM, David Chelimsky wrote:> On Jan 10, 2008 6:48 PM, Nathan Sutton <nathan.sutton at gmail.com> > wrote: >> You should browse over how shoulda does it here: >> http://thoughtbot.com/projects/shoulda/tutorial/controllers > > Or how others are supplying plugins for rspec: > > http://weblog.techno-weenie.net/2007/12/26/controller-specs-are-a-drag > http://git.caboo.se/?p=altered_beast.git;a=tree;f=vendor/plugins/rspec_on_rails_on_crack/lib;h=62b5fe1ccad8186a989f5d72dd218f3678fae518;hb=HEAD > >> >> and here: >> http://dev.thoughtbot.com/shoulda/classes/ThoughtBot/Shoulda/Controller/ClassMethods.html >> >> Nathan Sutton >> fowlduck at gmail.com >> rspec 1.1 >> rspec_on_rails 1.1 >> rails 2.0.2 >> >> >> On Jan 10, 2008, at 6:29 PM, Jonathan Leighton wrote: >> >>> On Thu, 2008-01-10 at 18:47 -0500, Josh Knowles wrote: >>>> On 1/10/08, Nathan Sutton <nathan.sutton at gmail.com> wrote: >>>>> Hmm, that includes a good number of them, but there''s still the >>>>> restful resource to think about, which is in my opinion the most >>>>> valuable one. Would you consider the addition of a restful >>>>> resource >>>>> matcher similar to shoulda''s? >>>> >>>> Yes. If you work something up I''d happily add it. Unfortunately I >>>> don''t have the need/time/desire to do it myself right now though. >>> >>> My reservation with the idea of "should be restful" is that you have >>> to >>> assume an awful lot about how the controller is implemented. That''s >>> fine >>> if you use scaffolding excessively but if you actually write your >>> own >>> code (!!) things quickly start to deviate from the trodden path. >>> >>> Recently I have been writing my controller specs a bit like this (I >>> have >>> some support code to enable it): >>> >>> describe PostsController do >>> controller_name :posts >>> stub_resource >>> >>> describe "when a post is viewed and the current user is an admin" do >>> log_in :as => :admin >>> get :show, :id => 42 >>> >>> it_should_find >>> it_should_load_awesome_admin_stuff >>> end >>> >>> describe "when a post is edited by a normal user" do >>> log_in :as => :prole >>> get :edit, :id => 23 >>> >>> it_should_find >>> it_should_warn >>> it_should_redirect_to "the post''s page", :at => "post_path(@post)" >>> end >>> end >>> >>> Some of the above is me using my creative license but you get the >>> idea. >>> Just thought it might spark some ideas/opinions... it''s certainly >>> not a >>> perfect implementation/API but I''ve found the general idea quite >>> useful. >>> I personally think this is the right level at which to make the >>> abstraction - you are still specifying the behaviour explicitly, >>> just >>> writing less code when doing it. >>> >>> Jon >>> >>> -- >>> Jonathan Leighton >>> http://jonathanleighton.com/ >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users