问题
SCENARIO
I have extracted a concern called Taggable
. It's a module that allows any model to support tagging. I have included this concern/module into models like User
, Location
, Places
, Projects
.
I want to write tests for this module, but don't know where to start.
QUESTION
1. Can I do isolation testing on the Taggable
concern?
In the example below the test fails because the test is looking for a dummy_class table
. I'm assuming it's doing this because of the has_many
code in Taggable
so as a result it expects 'DummyClass'
to be an ActiveRecord object.
# /app/models/concerns/taggable.rb
module Taggable
extend ActiveSupport::Concern
included do
has_many :taggings, :as => :taggable, :dependent=> :destroy
has_many :tags, :through => :taggings
end
def tag(name)
name.strip!
tag = Tag.find_or_create_by_name(name)
self.taggings.find_or_create_by_tag_id(tag.id)
end
end
# /test/models/concerns/taggable_test.rb
require 'test_helpers'
class DummyClass
end
describe Taggable do
before do
@dummy = DummyClass.new
@dummy.extend(Taggable)
end
it "gets all tags" do
@dummy.tag("dummy tag")
@dummy.tags.must_be_instance_of Array
end
end
Part of me thinks if I just test a model that has this module included inside of it like User
that's enough of a test. But I keep reading that you should test modules in isolation.
Looking for some guidance / strategy on what the right approach is.
回答1:
I would suggest having DummyClass
be a generic ActiveRecord::Base
child with very little custom code besides just include Taggable
, so that you would be isolating your concern module as much as possible but still being an AR class. Avoiding the use of one of your "real" classes like User
still isolates you from any other code in those classes, which seems valuable.
So something like this:
class DummyClass < ActiveRecord::Base; end
describe Taggable do
before do
@dummy_class = DummyClass.new
end
...
end
Since your DummyClass
may need to actually interact with the DB to test things like associations, you may need to create temporary tables in the DB during testing. The temping Ruby gem may be able to help with that, since its designed to create temporary ActiveRecord models and their underlying database tables.
Temping allows you to create arbitrary ActiveRecord models backed by a temporary SQL table for use in tests. You may need to do something like this if you're testing a module that is meant to be mixed into ActiveReord models without relaying on a concrete class.
回答2:
I went with using ActiveRecord Tableless rather than Temping gem, which seems to be a little out of date at the moment.
I set up my test up exactly the same as Stuart M has in his answer but included the has_no_table
helper method and columns required in my DummyClass.
class DummyClass < ActiveRecord::Base
# Use ActiveRecord tableless
has_no_table
# Add table columns
column :name, :string
# Add normal ActiveRecord validations etc
validates :name, :presence => true
end
This worked for what I needed to test, which was a module that extended ActiveRecord::Base
with a few additional methods, but I haven't tried it with any has_many
associations so it still might not help with what you wanted to test.
回答3:
Here is my solution of similar problem:
describe Taggable do
subject { mock_model('User').send(:extend, Taggable) }
it { should have_many(:tags) }
...
describe "#tag" do
...
end
end
In fact mock_model('User')
can mock any existent model in the system.
This is not an ideal solution but at least it's clear and mocks everything.
Note: mock_model
(AR mocks) were extracted to rspec-activemodel-mocks in rspec 3.0.
Also you need to use shoulda-matchers for associations matchers.
回答4:
As suggested in @StuartM's answer, using the temping gem worked for me:
# test.rb/spec.rb
Temping.create :dummy_class do
include Taggable
end
describe Taggable do
before do
@dummy = DummyClass.new
end
...
end
来源:https://stackoverflow.com/questions/15868210/testing-a-concern-module-that-uses-activerecord