Created
August 26, 2011 08:08
-
-
Save puyo/1172955 to your computer and use it in GitHub Desktop.
Is it possible to rspec this properly without hitting the database?
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
create_table "line_items", :force => true do |t| | |
t.integer "cost" | |
t.boolean "paid" | |
t.integer "order_id" | |
end | |
create_table "orders", :force => true do |t| | |
end | |
# ----- | |
class LineItem < ActiveRecord::Base | |
scope :paid, where(:paid => true) | |
end | |
# ----- | |
class Order < ActiveRecord::Base | |
has_many :line_items | |
def total_cost | |
line_items.paid.sum(:cost) | |
end | |
end | |
# ----- | |
require 'spec_helper' | |
describe Order do | |
let(:order) { Order.new(:line_items => line_items) } | |
describe '#total_cost' do | |
subject { order.total_cost } | |
context 'with line items costing 2 and 3 and 4 (unpaid)' do | |
before { order.save! } | |
let(:line_items) { | |
[ | |
LineItem.new(:cost => 2, :paid => true), | |
LineItem.new(:cost => 3, :paid => true), | |
LineItem.new(:cost => 4, :paid => false), | |
] | |
} | |
it { should == 5 } | |
end | |
context 'with no line items' do | |
let(:line_items) { [] } | |
it { should == 0 } | |
end | |
end | |
end |
Fixed it up but order.save! is necessary otherwise using a scope on unsaved data results in an empty collection being returned. Be nice if AREL supported in-memory equivalents.
I like the idea of creating a gem that allows you to do in memory AREL queries. If it could also allow you to test ActiveRecord callbacks without saving that would be nice as well.
That sounds pretty challenging but if it passed the AREL test suite (I haven't looked into it but I assume it has one and that it is reasonably complicated), then it would seem reasonable enough to run your unit tests against that instead of the database.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There might not be a perfect solution. We need to write a book about this. Or somebody does.
I think the code above isn't terrible though - it does execute your code and would most likely break if your implementation changed its intention. That seems a good measure of a test's quality. e.g. You could implement total_cost in a few ways and the test would still pass because of the duck typing relationship between Array and has-many-associations. It trades implementation agnosticism for speed in a pragmatic kinda way but keeps as much as it can out of the "it" block because it is not so relevant to the test.
I love judicious use of "let" and "subject" and I avoid passing strings to "it" for simple cases, nowadays. I think once you get used to that way of writing tests, they feel very succinct, easy to manipulate, DRY and express test cases nicely. It only took me months and months to figure it out. :-\
Incidentally, what do all those Rails TestUnit tests do in a similar situation? (I'm guessing they hit the DB.)