El 05/07/2010, a las 19:17, David Chelimsky escribió: > On Jul 5, 2010, at 11:58 AM, Wincent Colaiuta wrote: > >> El 05/07/2010, a las 18:18, David Chelimsky escribió: >> >>> The thing that concerns me the most is the DestinationParser. Even though >>> it seems simple, that's the sort of code that ends up making rspec-rails a >>> rails-dependent maintenance problem. >> >> But seeing as we're wrapping Rails assertions we're always going to be >> vulnerable to upstream changes. We're vulnerable to them right now in the >> existing route_to matcher. > > Sort of. What route_to relies on is a published API. If Rails changes the > meaning of assert_routing, that will impact all Rails users, not just rspec > users. > > This is a hot-button issue for me because relying on anything but published > APIs has led to frantic day-after-rails-release rspec-rails releases in the > past. Probably not really in an issue in this case, though. After looking at > it some more, DestinationParser isn't really relying on any code in Rails, > its relying on consistency in the routing API going forward. i.e. if Rails > stops supporting this format, DestinationParser won't break, but the concept > won't align correctly with Rails any longer. In this case, I think we're OK.
Yes, it's not doing any more than "route_to" is already doing (ie. preparing the parameters to be fed into "assert_routing"). It may have looked scarier than it was; I just wanted to stick it in a module so as not to repeat the code in each of the three matchers. >>> Anybody else besides me and Wincent and Matt want to weigh in here? >> >> Oops, does that mean I should stop posting? ;-) > > Immediately! > > Srsly, not a bit - just looking for other voices. Yes, would be good. To be honest, with a change like this (involving interface design), I think slowly is the way to go. Cheers, Wincent _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
