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.
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".
> 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?
> 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... 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? ;-)
Cheers,
Wincent
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
