Hi Cliff,
Hey, that's a good use case - one I hadn't considered. Just goes to
show you, the real world has a way of intruding on happy theories. :)
It's nice to hear feedback about the matcher.
which_generates() as a method on the route_to() matcher seems like it
should work to me, once it's w
Hi Cliff,
Hey, that's a good use case - one I hadn't considered. Just goes to
show you, the real world has a way of intruding on happy theories. :)
It's nice to hear feedback about the matcher.
which_generates() as a method on the route_to() matcher seems like it
should work to me, once it's w
On 1/11/10 9:22 PM, Nick Hoffman wrote:
> David Chelimsky wrote:
>
>> I'd recommend using the route_to matcher that was added in 1.2.9
>> instead.
>>
>> http://codepad.org/fLcxyA9N
>> http://rspec.rubyforge.org/rspec-rails/1.2.9/classes/Spec/Rails/Matchers.html#M29
>>
>> It's more reliable,
I guess the distinction is that you generate food_path()'s based on
existing food names, and search comes from users - but you don't have a
distinct landing page for each food, hence no need for resource-based
routing for foods.
You could define a :show action in your controller, which simply call
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 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
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:
>
Okay, following up on this item. Would you believe a workaround of (gasp) get
:index, prior to expecting route-based URLs to work? (slaps forehead). or
do_action(), provided by the host example group (the more concrete example
group, I mean - what's the right terminology there?).
I tried re
I'm encountering an interesting symptom during example execution. I'm making a
shared example group that dries up belongs-to-me before_filter testing, and it
makes a callback to the example group that says it_should_behave_like that.
The callback tells the shared example where to expect a red
Current code in cucumber prioritizes features/support/ files, but if I add
another file in that location, then it can (sometimes) include that file first.
Seems to depend on the number of files actually in the entire list being
sorted, or something.
I added a ticket for this issue.
http:/
Hi,
When upgrading to rspec/rspec-rails 1.2.6 gem (from 1.1.12), I'm having
a new problem verifying routes that should not exist.
This is to support something like this in routes.rb:
map.resources :orders do |orders|
orders.resources :items, :except => [:index,:show]
end
I used to use lambd
Hi again. I haven't heard any responses on this thread (is this thing
on? ;) .
Is there any known pattern for verifying a route that *doesn't* exist,
as of Rspec 1.2.6?
Thanks,
Randy
Randy Harmon wrote:
> Hi,
>
> When upgrading to rspec/rspec-rails 1.2.6 gem (from 1.1.12),
Hi again. I haven't heard any responses on this thread (is this thing
on? ;).
Is there any known pattern for verifying a route that *doesn't* exist,
as of Rspec 1.2.6?
Thanks,
Randy
Randy Harmon wrote:
> Hi,
>
> When upgrading to rspec/rspec-rails 1.2.6 gem (from 1.1.12),
Thanks, Ben.
>> NoMethodError in 'ItemsController route generation should NOT map
>> #indewfefwex'
>> You have a nil object when you didn't expect it!
>> You might have expected an instance of Array.
>> The error occurred while evaluating nil.first
>> /Library/Ruby/Gems/1.8/gems/actionpack-2.2.2/l
mortench wrote:
> The new rspec beta book and the rspec site mentions that it is
> possible to add a hash to "describe" and "it" constructs but very,
> very litle information about the particulars.
>
> What can the options hash be used for and what should it be used for?
>
>
This might be used f
On 6/12/09 1:43 AM, Matt Wynne wrote back to Lee who said:
>> I am wondering if there is a way to avoid having to specify params in
>> each and every example by adding some code to a before[:each] block?
> There are several ways of doing this. The pattern I tend to us is to
> create a method that d
16 matches
Mail list logo
