-
-
Save puyo/1172955 to your computer and use it in GitHub Desktop.
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 |
I will keep rewriting it and thinking about it and hopefully come up with something better.
I think when people are writing about testing practices it is often easy to come up with an example of how things should be done. When it comes to writing a test suite for a larger application I think a lot of "rules" start getting broken.
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.)
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.
Yeah that is bad. I think this is a great question you're asking and I don't think this gist is the best. It is testing the behaviour of Array#sum, not AR::Collection#sum (or whatever it actually is) and maybe it shouldn't be testing either - perhaps a simple should_receive is all you should be testing.