Comments on: Testing Rails: How to test Rails ActiveRecord Named Scopes

By: james2m

james2m — Sat, 31 Jul 2010 12:37:27 +0000

” setup do
@clients = 3.times.map { Invitation.make }
@advisors = 2.times.map { Invitation.make(:advisor) }
@creditors = 1.times.map { Invitation.make(:creditor) }
end

should “return only client invitations” do
assert_equal @clients, Invitation.clients
end

should “return only advisor invitations” do
assert_equal @advisors, Invitation.advisors
end

should “return only creditor invitations” do
assert_equal @creditor, Invitation.creditor
end”

By: Phillip

Phillip — Wed, 21 Apr 2010 17:06:42 +0000

I know it’s been many months since this post was made, but since comments are still open, I thought I’d toss in my 1/2 cent.

I agree with @James and @Peter. I’ve recently been catching myself paying too much attention to implementation and have had to back off a refocus on the intended behavior. There have been a few times in the past that I’ve implemented something one way and then come back and reworked it when business needs changed. Having a behavior-oriented test in place won’t be as brittle as an implementation-oriented and will allow you to properly refactor your code using the test as an indicator that the refactor is successful.

I agree with the respond_to? part though. I have a section in my spec for methods, delegates, and whatever else I may call in code to make sure I have defined them. Then I have another describe for the behavior. It works well for me.

Peace.

By: Peter

Peter — Fri, 21 Aug 2009 16:07:42 +0000

I agree with @James – you’re just testing the implementation of your proxy, which doesn’t make sense. Unit testing means testing the behaviour of the class or object as it appears to the outside world.

I did learn something neat tho – proxy_options is useful to know about. Thanks!

By: olivernn

olivernn — Tue, 11 Aug 2009 21:18:19 +0000

Sorry for posting on an old post, just thought I’d throw in how I test named_scopes. Instead of testing the actual methods for named_scope, which I would assume are fairly well tested, I want to make sure that a particular model has a named scope with the right conditions.

1
2
3

it "should have an active named_scope on status" do
Project.active.proxy_options.should == {:conditions => {:status => "active"}, :order => 'created_at DESC'}
end

I use rspec, but really I think the idea should be the same no matter what library for testing you use.

By: Simone Carletti

Simone Carletti — Thu, 18 Jun 2009 10:13:17 +0000

Hey James,
thanks for stopping by this post.

I agree with you in part and, what I probably forgot to say in my post, it that there are some situation where it actually makes sense to run a database query.

For instance, testing the raw proxy_options can cause a test to fail just because you are not coding the test in the same way you coded the scope.

In the following case, the test will fail even though the query would return the same recordset regardless you are using strings or symbols.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Foo < ActiveRecord::Base
named_scope :active, :conditions => { :active => true }
end

test "named_scope :active symbol" do # won't fail
expected = { :conditions => { :active => true } }
assert_equal expected, Foo.active.proxy_options
end

test "named_scope :active string" do # will fail
expected = { :conditions => { "active" => true } }
assert_equal expected, Foo.active.proxy_options
end

test "named_scope :active replacement" do # will fail
expected = { :conditions => ['active = ?', true] }
assert_equal expected, Foo.active.proxy_options
end

test "named_scope :active replacement with table" do # will fail
expected = { :conditions => ['foos.active = ?', true] }
assert_equal expected, Foo.active.proxy_options
end

This is probably the main reason why proxy_option might not be a good candidate for tests in some cases.

An other good one is that testing proxy_options doesn’t ensure you are passing invalid SQL statements to the database. This happened to me in some circumstances where I had to deal with SQLite in development mode and PostgreSQL in production or staging environment.

But the following one, IMHO, is probably a good candidate. Generally, I would prefer testing the specific proxy options when I have fair complex named_scopes (assuming you specifically want to use a named scope and not a classic method).

1
2
3

class Foo < ActiveRecord::Base
named_scope :latest, lambda { |*args| { :limit => (args.shift || nil), :order => "#{self.table_name}.created_at DESC" }}
end

In this case, you might want to setup a test to stress the different behaviors and eventually an other one to test the effective result of the query.

Many thanks for your comment. It gave me the opportunity to add some more details to the article. :)

By: James Adam

James Adam — Thu, 18 Jun 2009 09:48:10 +0000

I’m not sure I prefer this – you’re only testing the implementation details of the named scope here, rather than the desired behaviour.

At the very least you’d need to ensure that somewhere there was an integration test which properly exercised the method (which happens to be a named scope right now, but may not be in the future) against a set of matching and non-matching records.

I understand the desire to keep tests speedy and decoupled, but I think you’ll struggle to use your final suite of tests to refactor the implementation later on…