Model spec for file upload with paperclip and fastercsv

Testing RSpec
1

I just started my ImportsController and was this was really the way to
go:

////////import.rb/////////////////

class Import < ActiveRecord::Base
has_attached_file :csv
validates_attachment_presence :csv

after_save :process_csv

private
def process_csv
FasterCSV.foreach( csv.path) do |row|
#TODO
end
end

end

/////////import_spec.rb/////////////////

require ‘spec_helper’

describe Import do

it “should should succeed creating a valid Import from the factory” do
import = Factory.build(:import)
import.csv.stub!(:url).and_return("#{RAILS_ROOT}/spec/csv/3_products.csv")
import.save
end

describe “handling CSV files” do
describe “to import products” do

  before(:each) do
    @import = Factory.build(:import)
    @import.csv.stub!(:url).and_return("#{RAILS_ROOT}/spec/csv/3_products.csv")
  end

  def do_save
    @import.save
  end

  it "should process the csv file after save" do
    @import.should_receive(:process_csv)
    do_save
  end

  it "should load the csv file" do
    FasterCSV.should_receive(:foreach)
    do_save
  end

end

end
end

2

Now I have another weird error. My Products doesn’t save in the specs,
but it does in cucumber tests and human tests.
I’d be glad if someone could look into this.

http://pastie.org/693611

Ray

3

In the example that is failing, “should build 3 new Products” you have:

  it "should build 3 new Products" do
    # I have to tag this pending, this results in a weird error I

don’t have time for yet
# full stack testing with cucumber succeeds, human testing does
too
# pending
Product.should_receive(:new)
do_save
Product.count.should == 3
end

You are setting up an expectation with “should_receive(:new)”, and
you’re not supplying anything to be returned so it is defaulting to
nil. This is why you get the NoMethodError calling nil.save… because
your local variable product is nil for the duration of this example.

I don’t think you want to be using mocking down in the model spec like
you are doing. For example, does it really matter that #foreach was
called? Or that Product#new was called? Or that product#save was
called? These can all be inferred if you have a CSV file, save the
import ,and then suddenly you have products. No need to worry about
them directly IMO.

Using mocks in this example happen to make this spec brittle, and it
doesn’t add any value. For example, say you changed from using
fastercsv to some other csv library that had a different API, but it
properly parsed the CSV files. All of the behaviour of importing
products the CSV file still worked, but suddenly your examples fail
because #foreach isn’t be used. When focusing on the Import model
focus on the behaviour you want out of it. Based on the pastie you
made it seems like you want it to import products from a CSV after
save. So, you can write an example for ensuring the right number of
products were created. You might also want to write an example to
ensure the write fields from the CSV ended in the right attributes on
a product. Picking one or two products should be enough to gain
confidence.

I’ve done a quick edit of your original spec to show what I was
thinking when I quickly read your spec: http://pastie.org/693775

Hopefully this helps!

On Wed, Nov 11, 2009 at 8:48 AM, Ray K. [email protected] wrote:

rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

–
Zach D.
http://www.continuousthinking.com (personal)
http://www.mutuallyhuman.com (hire me)
http://ideafoundry.info/behavior-driven-development (first rate BDD
training)
@zachdennis (twitter)

4

Here’s a conclusion I’m drawing for myself.

With little prior experience, there’s only so much I could take with me
from one read through the rspec book.
Maybe it’s time to read it again.

5

Thanks for your input, I will try that later.

The reason why I posted here is, that it felt all wrong to spec my model
like this while writing it. It just wasn’t behavior driven, but
implementation driven.

Ray