Interesting Things
- If you have a “target” method on your model, things will get a bit weird when you try to access this method through an association. Since associations have their own “target” method, you actually need to call assocation.target.target, or probably better, don’t create methods called “target”.
- Since Time.now always returns the time for the local timezone, if you use it in your fixtures, but then have your app running under a different time zone, the times in your fixtures will be incorrect. Use the active support helpers such as 0.days.ago instead, or if you have a timezone configured in your environment, you can use Time.zone.now
Ask for Help
“How can I test the route helpers in RSpec? If I’m passing a complex set of options to a helper I’d like to test that it’s giving me what I expect.”
Nobody had any serious suggestions, although many humorous testing scenarios were mentioned.
Thanks for that target.target hint. We discovered the same strange behaviour but haven’t tracked it down yet. The target method was introduced in Rails 2.0 wasn’t it?
I thought that was worth a small thank you post on our blog: http://devblog.imedo.de/2008/8/11/stay-on-target
:)
Cheers,
Hendrik
August 11, 2008 at 5:44 pm
Glad it was helpful, [Josh](http://blog.hasmanythrough.com/) mentioned at standup this morning that proxy_target is an alias of target on the proxy. So you can use association.proxy_target.target which might be a bit more clear in your code.
August 12, 2008 at 6:15 pm
As for testing route helpers in RSpec, I found that this will work.
You’re testing this in a Helper, so pick one. Say, `application_helper_spec.rb`.
In your example, open up the helper and make the route helper you want to test public, then make an expectation as normal:
describe Foo do
it ‘should make the URL I want’ do
class < < helper
public(:custom_path)
end
helper.custom_path(:thing => ‘foo’).should == ‘/foo’
end
end
This seems to work.
August 12, 2008 at 8:13 pm