On Oct 19, 2010, at 2:05 AM, Wincent Colaiuta wrote:
> El 18/10/2010, a las 20:20, Joe Fiorini escribió:
>
>> I started testing routes for the first time in Rails 3 this weekend
>> during Rails Rumble. I was so exhausted that I found writing route
>> specs a very painful task. I came up with my own routing DSL and I'd
>> love to see it get included in RSpec itself. Before I start adding the
>> code to rspec-rails, I'd like to get some feedback and see if there
>> are some ways we could clean it up. Basically the DSL looks like:
>>
>> describe "My routes" do
>>
>> get "/blog" => { controller: "blogs-controller", action: "index" }
>>
>> end
>>
>> You can see all the details and the module used to make it work here:
>> http://gist.github.com/630176. Thoughts?
>
> I felt the same pain a while back and proposed a DSL too, but it never really
> got anywhere as there was no consensus about what a new DSL should look like.
> Full thread here:
>
>
> http://groups.google.com/group/rspec/browse_thread/thread/50b46ca3e4bd3a78/da928456061063c6
>
> I never got as far as submitting a patch because I didn't really like the
> alternative proposals so wasn't going to code them up (I'd already posted my
> own working proposal).
>
> After several iterations, the implementation that I am currently using
> consists of "map_to", "map_from", "have_routing" (ie. map both ways) and
> "be_recognized" matchers; these were chosen largely because they don't clash
> with the existing matchers in RSpec and so I can use them on an "opt-in"
> basis:
>
> http://gist.github.com/633716
>
> Some sample specs:
>
> http://gist.github.com/633723
>
> <tangent>
>
> One thing to note is how there are two assertions in there where I use
> "map_to" instead of "have_routing" because of what looks to be a bug in the
> Rails routing assertion macros. I think there is a Lighthouse ticket for this
> but the only ones related to "assert_generates" which I can find right now
> are:
>
> https://rails.lighthouseapp.com/projects/8994/tickets/5260
> https://rails.lighthouseapp.com/projects/8994/tickets/5005
> https://rails.lighthouseapp.com/projects/8994/tickets/5689
>
> At least one of those issues (#5260, #5005) is supposedly resolved in 3.0.2.
> #5698 was marked as invalid. Tangentially related is this old ticket which I
> posted:
>
> https://rspec.lighthouseapp.com/projects/5645/tickets/907
>
> I thought someone posted a pretty good analysis of exactly what the breakage
> is and why it happens, but I can't find it. :-( Guess when I get time will
> have to do some analysis of the Rails codebase and figure out what's
> happening and put together another ticket.
>
> While Googling, found this, however, describing changes in 2.0.0:
>
> http://github.com/rspec/rspec-rails/issues/221
>
> Which notes that RSpec's "route_to" now delegates to "assert_recognizes" (a
> one-way assertion) rather than "assert_routing" (a two-way assertion).
The problem with the bi-directional expectation was that you can have two
routes that map to the same path:
resources :widgets
root :to => "widgets#index"
In this case, both of these are true if all we expect is the route recognition:
{ :get => "/" }.should route_to(:controller => "widgets", :action => "index")
{ :get => "/widgets/index" }.should route_to(:controller => "widgets",
:action => "index")
However, route generation would not generate "/" from (:controller =>
"widgets", :action => "index"). Assuming a bi-directional mapping for every
case was wrong, so I changed it to uni-directional (route recognition).
The other 1/2 of the motivation for this change was that route generation is
something that is well specified and tested in Rails itself. In our apps, our
specs should spec things like "generates a link to the widget," not "builds a
link using the widget." So I don't see much value in expectations about
generation, and I certainly don't see them as a routing concern any longer.
They may be so within the rails framework, but they are unrelated to what I'm
specifying when I specify routes. Make sense?
So for me, all we need is uni-directional expectations for routes we want to
exist and routes we want to not exist, hence:
{ :get => "/" }.should route_to(:controller => "foo", :action => "bar")
{ :get => "/private_stuff" }.should_not be_routable
I would definitely be open to adding conveniences to clean this up:
get("/").should route_to("foo#bar")
get("/private_stuff").should_not be_routable
Then Joe's DSL could exploit those and we'd get:
get "/blog" => "blogs-controller#index"
Still not sure about the negative (unroutable).
Cheers,
David
> </tangent>
>
> Cheers,
> Wincent
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
