I want to test an inclusion of a module into a class. I am trying define a new class in RSpec:
describe Statusable do
let(:test_class) do
class ModelIncludingStatusable < ActiveRecord::Base
include Statusable
statuses published: "опубликовано", draft: "черновик"
end
end
describe '#statuses' do
it 'sets STATUSES for a model' do
test_class::STATUSES.should == ["опубликовано", "черновик"]
end
end
end
And I get an error:
TypeError:
[ActiveModel::Validations::InclusionValidator] is not a class/module
This is probably because in Statusable I have:
validates_inclusion_of :status, :in => statuses,
:message => "{{value}} должен быть одним из: #{statuses.join ','}"
But if I comment it out, I get:
TypeError:
["опубликовано", "черновик"] is not a class/module
Maybe new class definition isn't the best option, what do I do then? And even if it's not, how can I define a class in RSpec? And how do I fix this error?
Do not define new constant in tests otherwise it will pollute other tests. Instead, use stub_const.
Also, for this is an unit test of Statusable module. If ActiveRecord model is not a necessity, better not to use it.
You can also use class_eval to avoid not opening this class(no matter fake or not) actually
describe Statusable do
before do
stub_const 'Foo', Class.new
Foo.class_eval{ include Statusable }
Foo.class_eval{ statuses published: "foo", draft: "bar"}
end
context '#statuses' do
it 'sets STATUSES for a model' do
FOO::STATUSES.should == ["foo", "bar"]
end
end
end
Though I copied your assertion, I would suggest not to insert a constant say STATUS into the class/module(Foo) who includes this module. Instead, a class method would be better
expect(Foo.status).to eq(["foo", "bar"])
It fails because class definition does not return itself.
$ irb
> class Foo; 1 end
=> 1
you need to do like this:
let(:test_class) do
class ModelIncludingStatusable < ActiveRecord::Base
include Statusable
statuses published: "опубликовано", draft: "черновик"
end
ModelIncludingStatusable # return the class
end
It works but unfortunately, ModelIncludingStatusable will be defined on top-level because of ruby rule.
To capsulize your class, you should do like this:
class self::ModelIncludingStatusable < ActiveRecord::Base
include Statusable
statuses published: "опубликовано", draft: "черновик"
end
let(:test_class) do
self.class::ModelIncludingStatusable # return the class
end
It works perfectly :)
When you call let this define a memoized helper method. You can't class definition in method body.
Another option which I frequently use is to put the entire test in it's own module, e.g.
module Mapping::ModelSpec
module Human
Person = Struct.new(:name, :age, :posessions)
Possession = Struct.new(:name, :value)
end
RSpec.describe Mapping::Model do
it 'can map with base class' do
person = Human::Person.new('Bob Jones', 200, [])
...
end
end
end
While this is a bit cumbersome, it avoids polluting the global namespace, is only slightly more syntax, and is generally easy to understand. Personally, I'd like a better option.. but I'm not sure what that would be.
Related
Consider the following class and class method:
class Foo < ActiveRecord::Base
scope :active, -> { where(deleted: false) }
class << self
def some_class_method
active.each do |foo|
foo.some_instance_method
end
end
end
end
what is the best practice to test such a method in RSpec? What I have learned thus far suggests that I should make sure that each active instance of Foo receives a call to some_instance_method, but if I were to make an expectation regarding Foo.some_class_method, to my knowledge I cannot assert a nested expectation about any instance of Foo.
Any help would be appreciated!!
The approach I would take is to separately test some_instance_method, like:
it 'should return some value' do
expect(foo.some_instance_method).to eq('some value')
end
You could then run the class method and test that the transformations happened as expected:
context 'Foo#some_class_method' do
it 'should have some effect' do
expect(some_comparison_variable).to eq('some_before_state')
Foo.some_class_method
expect(some_comparison_variable).to eq('some_after_state')
end
end
I have a Concern defined like this:
module Shared::Injectable
extend ActiveSupport::Concern
module ClassMethods
def injectable_attributes(attributes)
attributes.each do |atr|
define_method "injected_#{atr}" do
...
end
end
end
end
and a variety of models that use the concern like this:
Class MyThing < ActiveRecord::Base
include Shared::Injectable
...
injectable_attributes [:attr1, :attr2, :attr3, ...]
...
end
This works as intended, and generates a set of new methods that I can call on an instance of the class:
my_thing_instance.injected_attr1
my_thing_instance.injected_attr2
my_thing_instance.injected_attr3
My issue comes when I am trying to test the concern. I want to avoid manually creating the tests for every model that uses the concern, since the generated functions all do the same thing. Instead, I thought I could use rspec's shared_example_for and write the tests once, and then just run the tests in the necessary models using rspec's it_should_behave_like. This works nicely, but I am having issues accessing the parameters that I have passed in to the injectable_attributes function.
Currently, I am doing it like this within the shared spec:
shared_examples_for "injectable" do |item|
...
describe "some tests" do
attrs = item.methods.select{|m| m.to_s.include?("injected") and m.to_s.include?("published")}
attrs.each do |a|
it "should do something with #{a}" do
...
end
end
end
end
This works, but is obviously a horrible way to do this. Is there an easy way to access only the values passed in to the injectable_attributes function, either through an instance of the class or through the class itself, rather than looking at the methods already defined on the class instance?
Since you say that you "want to avoid manually creating the tests for every model that uses the concern, since the generated functions all do the same thing", how about a spec that tests the module in isolation?
module Shared
module Injectable
extend ActiveSupport::Concern
module ClassMethods
def injectable_attributes(attributes)
attributes.each do |atr|
define_method "injected_#{atr}" do
# method content
end
end
end
end
end
end
RSpec.describe Shared::Injectable do
let(:injectable) do
Class.new do
include Shared::Injectable
injectable_attributes [:foo, :bar]
end.new
end
it 'creates an injected_* method for each injectable attribute' do
expect(injectable).to respond_to(:injected_foo)
expect(injectable).to respond_to(:injected_bar)
end
end
Then, as an option, if you wanted to write a general spec to test whether an object actually has injectable attributes or not without repeating what you've got in the module spec, you could add something like the following to your MyThing spec file:
RSpec.describe MyThing do
let(:my_thing) { MyThing.new }
it 'has injectable attributes' do
expect(my_thing).to be_kind_of(Shared::Injectable)
end
end
What about trying something like this:
class MyModel < ActiveRecord::Base
MODEL_ATTRIBUTES = [:attr1, :attr2, :attr3, ...]
end
it_behaves_like "injectable" do
let(:model_attributes) { MyModel::MODEL_ATTRIBUTES }
end
shared_examples "injectable" do
it "should validate all model attributes" do
model_attributes.each do |attr|
expect(subject.send("injected_#{attr}".to_sym)).to eq (SOMETHING IT SHOULD EQUAL)
end
end
end
It doesn't create individual test cases for each attribute, but they should all have an assertion for each attribute. This might at least give you something to work from.
I have a function that does this:
def blank_to_negative(value)
value.is_number? ? value : -1
end
If the value passed is not a number, it converts the value to -1.
I mainly created this function for a certain model, but it doesn't seem appropriate to define this function in any certain model because the scope of applications of this function could obviously extend beyond any one particular model. I'll almost certainly need this function in other models, and probably in views.
What's the most "Rails Way" way to define this function and then use it everywhere, especially in models?
I tried to define it in ApplicationHelper, but it didn't work:
class UserSkill < ActiveRecord::Base
include ApplicationHelper
belongs_to :user
belongs_to :skill
def self.splice_levels(current_proficiency_levels, interest_levels)
Skill.all.reject { |skill| !current_proficiency_levels[skill.id.to_s].is_number? and !interest_levels[skill.id.to_s].is_number? }.collect { |skill| {
:skill_id => skill.id,
:current_proficiency_level => blank_to_negative(current_proficiency_levels[skill.id.to_s]),
:interest_level => blank_to_negative(interest_levels[skill.id.to_s]) }}
end
end
That told me
undefined method `blank_to_negative' for #
I've read that you're "never" supposed to do that kind of thing, anyway, so I'm kind of confused.
if you want to have such a helper method in every class in your project, than you are free to add this as a method to Object or whatever you see fits:
module MyApp
module CoreExtensions
module Object
def blank_to_negative
self.is_number? ? self : -1
end
end
end
end
Object.send :include, MyApp::CoreExtensions::Object
There are a few options:
Monkey-patch the method into ActiveRecord and it will be available across all of your models:
class ActiveRecord::Base
def blank_to_negative(value)
value.is_number? ? value : -1
end
end
Add a "concern" module which you then mix into selected models:
# app/concerns/blank_to_negate.rb
module BlankToNegate
def blank_to_negative(value)
value.is_number? ? value : -1
end
end
# app/models/user_skill.rb
class UserSkill < ActiveRecord::Base
include BlankToNegate
# ...
end
Ruby Datatypes functionality can be extended. They are not sealed. Since you wan to use it in all places why not extend FIXNUM functionality and add a method blank_to_negative to it.
Here's what I ended up doing. I put this code in config/initializers/string_extensions.rb.
class String
def is_number?
true if Float(self) rescue false
end
def negative_if_not_numeric
self.is_number? ? self : -1
end
end
Also, I renamed blank_to_negative to negative_if_not_numeric, since some_string.negative_if_not_numeric makes more sense than some_string.blank_to_negative.
I'm having a problem testing for methods that correspond to the database columns of an ActiveRecord. Take any model you've got (in my case Document), and do the following:
$ rails c
Loading development environment (Rails 3.0.9)
>> Document.method_defined?(:id)
=> false
>> Document.new
=> #<Document id: nil, feed_id: nil >
>> Document.method_defined?(:id)
=> true
There is obviously some ActiveRecord lifecycle work going on as a prerequisite to .new() that's adding all the database columns as methods to the class.
Where this really complicates things is during unit testing. I'd like have a class that in runtime accepts ActiveRecord classes and does some validation on them
For example
class Foo < ActiveRecord::Base
def work1
# something
end
end
class Command
def operates_on(clazz, method)
# unless I add a "clazz.new" first, method_defined? will fail
# on things like :id and :created_at
raise "not a good class #{clazz.name}" if ! clazz.method_defined?(method)
# <logic here>
end
end
describe Command do
it "should pass if given a good class" do
Command.new.operates_on(Foo,:work1)
end
it "should pass if given a database column" do
# this FAILS
Command.new.operates_on(Foo,:id)
end
it "should raise if given an invalid class/method combo" do
lambda { Command.new.operates_on(Foo,:non_work) }.should raise_error
end
end
What can I do to assert (other than making a junk instance with .new()) that the ActiveRecord has done its initialization?
This appears to be a bug but isn't likely going to be fixed soon.
Inconsistent method_defined? behaviour
I found that .attribute_method? works on the class to do what you need. You can find more information at ActiveRecord::AttributeMethods::ClassMethods
I use a decorator module that get's included in a model instance (through the "extends" method). So for example :
module Decorator
def foo
end
end
class Model < ActiveRecord::Base
end
class ModelsController < ApplicationController
def bar
#model = Model.find(params[:id])
#model.extend(Decorator)
#model.foo
end
end
Then I would like in the tests to do the following (using Mocha) :
test "bar" do
Model.any_instance.expects(:foo).returns("bar")
get :bar
end
Is this possible somehow, or do you have in mind any other way to get this functionality???
Just an Assumption Note: I will assume that your Decorator foo method returns "bar" which is not shown in the code that you sent. If I do not assume this, then expectations will fail anyway because the method returns nil and not "bar".
Assuming as above, I have tried the whole story as you have it with a bare brand new rails application and I have realized that this cannot be done. This is because the method 'foo' is not attached to class Model when the expects method is called in your test.
I came to this conclusion trying to follow the stack of called methods while in expects. expects calls stubs in Mocha::Central, which calls stubs in Mocha::ClassMethod, which calls *hide_original_method* in Mocha::AnyInstanceMethod. There, *hide_original_method* does not find any method to hide and does nothing. Then Model.foo method is not aliased to the stubbed mocha method, that should be called to implement your mocha expectation, but the actual Model.foo method is called, the one that you dynamically attach to your Model instance inside your controller.
My answer is that it is not possible to do it.
It works (confirmed in a test application with render :text)
I usually include decorators (instead of extending them at runtime) and I avoid any_instance since it's considered bad practice (I mock find instead).
module Decorators
module Test
def foo
"foo"
end
end
end
class MoufesController < ApplicationController
def bar
#moufa = Moufa.first
#moufa.extend(Decorators::Test)
render :text => #moufa.foo
end
end
require 'test_helper'
class MoufesControllerTest < ActionController::TestCase
# Replace this with your real tests.
test "bar" do
m = Moufa.first
Moufa.expects(:find).returns(m)
m.expects(:foo).returns("foobar")
get :bar, {:id => 32}
assert_equal #response.body, "foobar"
end
end
Ok, now I understand. You want to stub out a call to an external service. Interesting that mocha doesn't work with extend this way. Besides what is mentioned above, it seems to be because the stubbed methods are defined on the singleton class, not the module, so don't get mixed in.
Why not something like this?
test "bar" do
Decorator = Module.new{ def foo; 'foo'; end }
get :bar
end
If you'd rather not get the warnings about Decorator already being defined -- which is a hint that there's some coupling going on anyway -- you can inject it:
class ModelsController < ApplicationController
class << self
attr_writer :decorator_class
def decorator_class; #decorator_class ||= Decorator; end
end
def bar
#model = Model.find(params[:id])
#model.extend(self.class.decorator_class)
#model.foo
end
end
which makes the test like:
test "bar" do
dummy = Module.new{ def foo; 'foo'; end }
ModelsController.decorator_class = dummy
get :bar
end
Of course, if you have a more complex situation, with multiple decorators, or decorators defining multiple methods, this may not work for you.
But I think it is better than stubbing the find. You generally don't want to stub your models in an integration test.
One minor change if you want to test the return value of :bar -
test "bar" do
Model.any_instance.expects(:foo).returns("bar")
assert_equal "bar", get(:bar)
end
But if you are just testing that a model instance has the decorator method(s), do you really need to test for that? It seems like you are testing Object#extend in that case.
If you want to test the behavior of #model.foo, you don't need to do that in an integration test - that's the advantage of the decorator, you can then test it in isolation like
x = Object.new.extend(Decorator)
#.... assert something about x.foo ...
Mocking in integration tests is usually a code smell, in my experience.