Is it possible to rspec this properly without hitting the database?

order_spec.rb

  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 might be missing something but I think line 21 will raise an error because line_items hasn't been defined, right?

Run it and see. :-) let is all in your face with lazy-evaluationy.

By the time the "it" gets executed, let(:line_items) has been executed, so it is defined.

I'm just having another look at this codes example and noticed you are stubbing out the line_items method on the order object.

What are your thoughts on stubbing out methods on the object under test? I've been told in the past that it's isn't a good thing to do.

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.

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.