On Aug 17, 2010, at 12:46 PM, Michael Kintzer wrote:
> On Jul 7, 11:25 pm, Wincent Colaiuta 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
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 wrote:
>
> So, when I see this kind of thing, I
El 08/07/2010, a las 04:45, Lalish-Menagh, Trevor escribió:
> OK, here is an idea. I was thinking about how to make routing tests
> that make sense. I agree with Wincent that the Rails verbiage for the
> routing tests is confusing, but what is NOT confusing is the new
> routing format, so why not
OK, here is an idea. I was thinking about how to make routing tests
that make sense. I agree with Wincent that the Rails verbiage for the
routing tests is confusing, but what is NOT confusing is the new
routing format, so why not try out this format
(http://gist.github.com/467563):
describe 'routi
El 07/07/2010, a las 16:42, David Chelimsky escribió:
> On Jul 7, 2010, at 7:39 AM, Wincent Colaiuta wrote:
>
>> El 07/07/2010, a las 13:29, David Chelimsky escribió:
>
> How about going back to map, with to_and_from:
>
> it { should map(get "/issues/new").to_and_from("issues#new") }
>
>
On Jul 7, 2010, at 7:39 AM, Wincent Colaiuta wrote:
> El 07/07/2010, a las 13:29, David Chelimsky escribió:
>
>> Seems as though this format has been abandoned in this conversation:
>>
>> it { should route(get "/issues/new").to("issues#new") }
>> it { should generate("/issues/new").from("issues
El 07/07/2010, a las 13:29, David Chelimsky escribió:
> Seems as though this format has been abandoned in this conversation:
>
> it { should route(get "/issues/new").to("issues#new") }
> it { should generate("/issues/new").from("issues#new") }
>
> I think that verbiage is concise and intention
On Jul 7, 2010, at 1:24 AM, Wincent Colaiuta wrote:
> El 07/07/2010, a las 01:16, Lalish-Menagh, Trevor escribió:
>
>> Hi David,
>>
>> You make a good point. I was talking with a coworker about this
>> problem, and he suggested a simpler format, that I think will coincide
>> some with Wincent's
El 07/07/2010, a las 01:16, Lalish-Menagh, Trevor escribió:
> Hi David,
>
> You make a good point. I was talking with a coworker about this
> problem, and he suggested a simpler format, that I think will coincide
> some with Wincent's thoughts. Here is my next stab
> (http://gist.github.com/46606
Hi David,
You make a good point. I was talking with a coworker about this
problem, and he suggested a simpler format, that I think will coincide
some with Wincent's thoughts. Here is my next stab
(http://gist.github.com/466064):
describe "routing" do
it "recognizes and generates #index" do
g
On Jul 5, 2010, at 2:59 PM, Lalish-Menagh, Trevor wrote:
> OK, I will chime in here, since I think I might have opened up this
> can of worms. :)
>
> I agree with David that we should stick with wrapping the Rails public
> APIs. That is: assert_generates, assert_recognizes, and assert_routing
> (h
El 05/07/2010, a las 20:18, Randy Harmon escribió:
> I'm uncertain about the need to easily specify one-directional routes.
> While in theory it sounds fine, I don't understand why you'd want to
> specify either a route that isn't recognized (why bother routing it, in
> this case?) or one that do
OK, I will chime in here, since I think I might have opened up this
can of worms. :)
I agree with David that we should stick with wrapping the Rails public
APIs. That is: assert_generates, assert_recognizes, and assert_routing
(http://edgeapi.rubyonrails.org/classes/ActionDispatch/Assertions/Routi
El 05/07/2010, a las 21:00, Randy Harmon escribió:
> David Chelimsky wrote:
>> Check out these two threads:
>>
>> http://groups.google.com/group/rspec/browse_thread/thread/9ac4ff6f3bac8423
>> http://groups.google.com/group/rspec/browse_thread/thread/4775eaa9b8b3c25f
>>
>> Both of them were, coin
David Chelimsky wrote:
> ps - I moved your post to the bottom - please bottom/inline post
> instead of top-posting (http://idallen.com/topposting.html).
Sorry, perhaps I should have deleted most of the quotey bits, since I
was replying very generally to the thread.
> Check out these two threads:
>
On 7/5/10 2:14 AM, Matt Wynne wrote:
> Seems like progress. One thought: Why not use a macro-style syntax to
> eliminate the boring boilerplate call to #it / #example and generate examples
> instead?
I thought this was an insightful comment. Riffing on that, I get what
clearly becomes a DSL alon
I'll chime in, having contributed some of the mess at hand.
Good things I'm seeing between current route helpers and proposals include:
* The router being at the center of what's being tested
* Similarity of specs to other conventions
* Ability to specify bi-directional routing behavior (by defa
On Jul 5, 2010, at 12:38 PM, Wincent Colaiuta wrote:
> 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 DestinationPars
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 t
El 05/07/2010, a las 18:58, Wincent Colaiuta escribió:
> El 05/07/2010, a las 18:18, David Chelimsky escribió:
>
>> 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()"
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 maintenan
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'
On Jul 5, 2010, at 9:04 AM, Wincent Colaiuta wrote:
> El 05/07/2010, a las 13:56, David Chelimsky escribió:
>
>> Nice overall. Much of the code belongs in Rails, though, so I'd like to try
>> to get a patch in to Rails once we get this worked out. I'd like the
>> rspec-rails matchers to be simp
El 05/07/2010, a las 13:56, David Chelimsky escribió:
> Nice overall. Much of the code belongs in Rails, though, so I'd like to try
> to get a patch in to Rails once we get this worked out. I'd like the
> rspec-rails matchers to be simple wrappers for rails' assertions wherever
> possible.
We
On Jul 5, 2010, at 4:14 AM, Matt Wynne wrote:
> On 5 Jul 2010, at 08:00, Wincent Colaiuta wrote:
>> Hi folks,
>>
>> I've been unhappy with routing specs for a long time now and last night when
>> updating some old 1.3 specs for 2.0 I decided to see if I could come up with
>> something that didn'
On 5 Jul 2010, at 08:00, Wincent Colaiuta wrote:
> Hi folks,
>
> I've been unhappy with routing specs for a long time now and last night when
> updating some old 1.3 specs for 2.0 I decided to see if I could come up with
> something that didn't make me feel unhappy.
>
> Principal causes of un
Hi folks,
I've been unhappy with routing specs for a long time now and last night when
updating some old 1.3 specs for 2.0 I decided to see if I could come up with
something that didn't make me feel unhappy.
Principal causes of unhappiness:
1. Historically we had "route_for" and "params_from",
27 matches
Mail list logo
