[rspec-users] Possible improvements to routing spec API

Wincent Colaiuta win at wincent.com
Mon Jul 5 13:38:09 EDT 2010


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



More information about the rspec-users mailing list