There David goes, making sense again. Nathan Sutton [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> > 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 >> [EMAIL PROTECTED] >> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> web: http://joshknowles.com >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
