[rspec-users] Possible improvements to routing spec API

Michael Kintzer rockrep at gmail.com
Tue Aug 17 13:46:54 EDT 2010


Lots of good proposals here.  I would at least like to chime in that I
agree with the goals as set out by Wincent below, and from a
readability standpoint have preferred the API as suggested by
Trevor.

-Michael

On Jul 7, 11:25 pm, Wincent Colaiuta <w... at wincent.com> wrote:
>
> So, when I see this kind of thing, I think _what_ are we trying to achieve in ourroutingspecs and _why_? At least for me, the answers are:
>
>   1. Confirm: To confirm that the routes I've defined actually do what I think they do
>
>   2. Describe: To serve as a complete, explicit, readable specification of the behavior I expect from my routes
>
> And finally:
>
>   3. That the Railsroutingcode actually works as advertised
>
> This last one is a bit dubious, but the truth is the Rails 3 router is a complete re-write and bugs in it and incompatibilities with the old router are being found and squished constantly. An exhaustive set ofroutingspecs can definitely help to uncover undiscovered edge cases.
>
> So, bearing in mind those goals, what I actually need from RSpec in order to achieve them is:
>
>   - most importantly, a way of asserting that a user action (eg. HTTP verb + path + params) gets routed to a given controller + action with certain additional parameters (ie. a wrapper for assert_recognizes)
>
>   - less importantly, a way of asserting that a set of params (action, controller, additional params) generates a particular path (ie. a wrapper for assert_generates); this is less important for me because in practice close to all (98%) of my URL generation is done with named URL helpers, and I can test those explicitly if I want
>
>   - as syntactic sugar, a way of combining the above two assertions into one for those cases where the mapping is perfectly bidirectional (ie. a wrapper for assert_routing).
>
> With these tools I can achieve pretty much everything I need: not only test that user actions end up hitting the right spots in my application, but also specify clearly and explicitly what I expect those mappings to be.
>
> So for me, anything else doesn't really help me achieve my goals. The "have_resource(s)" matcher, for instance, doesn't help me and in fact actually undermines my goal of providing a complete and explicit specification of how my routes work.
>
> The "recognize" and "generate" matchers you suggest obviously are "on target" to help me fulfill my goals. Of these, the "recognize" one is the most important one though.
>
> Of the "match" and "get" matchers you suggest, seeing as they both wrap the same thing (assert_routing), one of them would have to go. I'd probably ditch "match" because it is just a repetition of the router DSL method of the same name, and my goal here isn't just to repeat that DSL in my specs.
>
> In fact, if you look at my most important goal -- asserting that a user action (HTTP verb, path, params) hits a specific end point (controller + action + additional params) -- you'll understand why, in my proposal, all of my specifications start with "get"/"post" etc followed by path, params and then controller/action. It's not just for resonance with other parts of RSpec like where we use "get" etc in controller specs.
>
> But if the goal is just to wrap the 3 Rails assertions as faithfully as possible, then you wind up with a different proposal. What David has posted is probably the closest to this goal.
>
> And if the goal is make the specs map as closely as possible onto the language of config/routes.rb, then you wind up with a different proposal still... (ie. the one you just made).
>
> So, I guess what I'm saying here is I'd like to hear _what_ people are wanting to achieve in theirroutingspecs and _why_; and then to ask what kind of means RSpec should provide to best achieve those goals.
>
> Cheers,
> Wincent
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users


More information about the rspec-users mailing list