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.
> As I see it the purpose of the DestinationParser is to just take the user's
> parameters in the spec file (a format which we control, designed to make
> specs read nicely) and put them in a format that
> assert_(recognizes|generates|routing) expects (a format that the Rails team
> controls, designed according to their own criteria). If they ever change
> their format, they'll break thousands of users' specs, whether or not we have
> a "DestinationParser".
Right :)
>> Slight tangent - one nice thing about 'recognize' as a matcher name is we
>> get this for free:
>>
>> it { should_not recognize(:get => '/wiki/foo') }
>
> True, but with "get()" we can already do:
>
> it { get('/wiki/foo').should_not be_routable }
>
> Which is effectively the same isn't it?
Effectively, yes, but I'm liking "recognize" better than "be_routable".
>> The point of "it' is that it reads as part of a sentence:
>>
>> describe "something" do
>> it "does something"
>>
>> When we introduced the implicit subject, we got this:
>>
>> describe "something" do
>> it { should do_something }
>>
>> In that form it still reads nicely: "it should do something".
>>
>> In this case, saying "it get post issues should map issues#create" makes me
>> want to cry.
>
> Yes, I know what you mean.
>
>> We've still got example and specify.
>
> Knew about example, had forgotten about specify... now that one goes a
> loooooong way back doesn't it?
>
>>> IssuesController
>>> routing
>>> should map POST /issues as issues#create
>>> should map GET /issues as issues#index
>>> should map GET /issues/new as issues#new
>>> should map GET /issues/123 as issues#show with {:id=>"123"}
>>> should map GET /issues/123/edit as issues#edit with {:id=>"123"}
>>> should map PUT /issues/123 as issues#update with {:id=>"123"}
>>> should map DELETE /issues/123 as issues#destroy with {:id=>"123"}
>>>
>>> Which IMO looks pretty nice.
>>
>> It does, though seeing that last output makes me wonder about the "map/as"
>> verbiage. Seems less clear in this context for some reason.
>
> I think it would read quite nicely as "should map something _to_ something",
> but that puts us back in the old "uni-directional" word for "bi-directional"
> relationship problem. I was trying to have:
>
> - "should map X to Y" correspond to map_to/assert_recognizes
> - "should map X from Y" correspond to map_from/assert_generates
> - "should map X as Y" correspond to map/assert_routing
> One possibility that I've been toying with is substituting "route" for "map"
> here, but "route_to" clashes with the existing "route_to" matcher in RSpec,
> and I am not sure that it buys us anything anyway...
I think "map" is working for me in this context. The word "route" suggests
"take a path and route it to a destination", whereas "map" suggests "these two
things are related, so map one to the other", at which point [to|from|as]
provide more context as to the nature of the relationship.
> As you said earlier on, language is hard...
>> 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.
Cheers,
David
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
