blocks|key|1435373|text|rad+=>|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1435374|let(:dummy_class)+{+Class.new+{+include+ModuleToBeTested+}+}|code-block|syntax|javascript|1435375|或者，您可以使用您的模块扩展测试类：|1435376|let(:dummy_class)+{+Class.new+{+extend+ModuleToBeTested+}+}|1435377|使用'let‘比使用实例变量来定义之前的(：each)中的虚拟类要好。|1435378|When+to+use+RSpec+let()?|offset|length|1435379|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/5359558/when-to-use-rspec-let^0|0|0|0|0|0|0|O|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|11|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@$O|14|P|15|1|16]]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$S|$5|T|U|V|A|$W|X]]]]

The rad way =>

<pre><code>let(:dummy_class) { Class.new { include ModuleToBeTested } }
</code></pre>

Alternatively you can extend the test class with your module: 

<pre><code>let(:dummy_class) { Class.new { extend ModuleToBeTested } }
</code></pre>

Using 'let' is better than using an instance variable to define the dummy class in the before(:each)

<a href="https://stackoverflow.com/questions/5359558/when-to-use-rspec-let">When to use RSpec let()?</a>

blocks|key|1220311|text|迈克说的话。下面是一个简单的例子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1220312|模块代码...|1220313|module+Say
++def+hello
++++"hello"
++end
end|code-block|syntax|javascript|1220314|规范片段...|1220315|class+DummyClass
end

before(:each)+do
++@dummy_class+=+DummyClass.new
++@dummy_class.extend(Say)
end

it+"get+hello+string"+do
++expect(@dummy_class.hello).to+eq+"hello"
end|1220316|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

What mike said. Here's a trivial example:

module code...

<pre><code>module Say
 def hello
 "hello"
 end
end
</code></pre>

spec fragment...

<pre><code>class DummyClass
end

before(:each) do
 @dummy_class = DummyClass.new
 @dummy_class.extend(Say)
end

it "get hello string" do
 expect(@dummy_class.hello).to eq "hello"
end
</code></pre>

blocks|key|1220408|text|对于可以单独测试或通过模拟类进行测试的模块，我喜欢以下内容：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1220409|模块：|1220410|module+MyModule
++def+hallo
++++"hallo"
++end
end|code-block|syntax|javascript|1220411|规格：|1220412|describe+MyModule+do
++include+MyModule

++it+{+hallo.should+==+"hallo"+}
end|1220413|劫持嵌套的示例组似乎是错误的，但我喜欢它的简洁性。有什么想法吗？|1220414|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

For modules that can be tested in isolation or by mocking the class, I like something along the lines of:

module:

<pre><code>module MyModule
 def hallo
 "hallo"
 end
end
</code></pre>

spec:

<pre><code>describe MyModule do
 include MyModule

 it { hallo.should == "hallo" }
end
</code></pre>

It might seem wrong to hijack nested example groups, but I like the terseness. Any thoughts?

blocks|key|1435258|text|在我的脑海中，你能在你的测试脚本中创建一个虚拟类，并在其中包含模块吗？然后测试虚拟类的行为是否符合您的预期。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1435259|编辑:如果正如注释中指出的那样，模块希望某些行为出现在它混合到的类中，那么我会尝试实现这些行为的虚拟。足够让模块愉快地执行它的职责。|1435260|也就是说，当一个模块对它的宿主有很大的期望时，我会对我的设计感到有点紧张(我们说“宿主”吗？)类-如果我还没有从基类继承，或者不能将新功能注入到继承树中，那么我认为我会尽量减少模块可能具有的任何这样的期望。我担心的是我的设计会开始发展出一些令人不快的不灵活的地方。|1435261|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Off the top of my head, could you create a dummy class in your test script and include the module into that? Then test that the dummy class has the behaviour in the way you'd expect.

EDIT: If, as pointed out in the comments, the module expects some behaviours to be present in the class into which it's mixed, then I'd try to implement dummies of those behaviours. Just enough to make the module happy to perform its duties.

That said, I'd be a little nervous about my design when a module expects a whole lot from its host (do we say "host"?) class - If I don't already inherit from a base class or can't inject the new functionality into the inheritance tree then I think I'd be trying to minimise any such expectations that a module might have. My concern being that my design would start to develop some areas of unpleasant inflexibility.

blocks|key|1435615|text|我最近的工作，使用尽可能少的硬连接|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1435616|require+'spec_helper'

describe+Module::UnderTest+do
++subject+{Object.new.extend(described_class)}

++context+'.module_method'+do
++++it+{is_expected.to+respond_to(:module_method)}
++++#+etc+etc
++end
end|code-block|syntax|javascript|1435617|我希望|1435618|subject+{Class.new{include+described_class}.new}|1435619|起作用了，但没有(就像Ruby+MRI+2.2.3和RSpec::Core+3.3.0一样)|1435620|Failure/Error:+subject+{Class.new{include+described_class}.new}
++NameError:
++++undefined+local+variable+or+method+`described_class'+for+#<Class:0x000000063a6708>|1435621|显然，described_class在该范围内不可见。|1435622|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

my recent work, using as little hard-wiring as possible

<pre><code>require 'spec_helper'

describe Module::UnderTest do
 subject {Object.new.extend(described_class)}

 context '.module_method' do
 it {is_expected.to respond_to(:module_method)}
 # etc etc
 end
end
</code></pre>

I wish 

<pre><code>subject {Class.new{include described_class}.new}
</code></pre>

worked, but it doesn't (as at Ruby MRI 2.2.3 and RSpec::Core 3.3.0)

<pre><code>Failure/Error: subject {Class.new{include described_class}.new}
 NameError:
 undefined local variable or method `described_class' for #&lt;Class:0x000000063a6708&gt;
</code></pre>

Obviously described_class isn't visible in that scope.

blocks|key|1220431|text|下面是什么：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1220432|describe+MyModule+do
++subject+{+Object.new.extend(MyModule)+}
++it+"does+stuff"+do
++++expect(subject.does_stuff?).to+be_true
++end
end|code-block|syntax|javascript|1220433|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

What about:

<pre><code>describe MyModule do
 subject { Object.new.extend(MyModule) }
 it "does stuff" do
 expect(subject.does_stuff?).to be_true
 end
end
</code></pre>

blocks|key|1435505|text|我建议，对于更大、更常用的模块，应该选择@Andrius+here建议的“共享示例组”。对于简单的东西，你不想经历多个文件等的麻烦，下面是如何确保最大限度地控制你的虚拟东西的可见性(使用rspec+2.14.6测试，只需将代码复制并粘贴到规范文件中并运行它)：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1435506|module+YourCoolModule
++def+your_cool_module_method
++end
end

describe+YourCoolModule+do
++context+"cntxt1"+do
++++let(:dummy_class)+do
++++++Class.new+do
++++++++include+YourCoolModule

++++++++#Say,+how+your+module+works+might+depend+on+the+return+value+of+to_s+for
++++++++#the+extending+instances+and+you+want+to+test+this.+You+could+of+course
++++++++#just+mock/stub,+but+since+you+so+conveniently+have+the+class+def+here
++++++++#you+might+be+tempted+to+use+it?
++++++++def+to_s
++++++++++"dummy"
++++++++end

++++++++#In+case+your+module+would+happen+to+depend+on+the+class+having+a+name
++++++++#you+can+simulate+that+behaviour+easily.
++++++++def+self.name
++++++++++"DummyClass"
++++++++end
++++++end
++++end

++++context+"instances"+do
++++++subject+{+dummy_class.new+}

++++++it+{+subject.should+be_an_instance_of(dummy_class)+}
++++++it+{+should+respond_to(:your_cool_module_method)}
++++++it+{+should+be_a(YourCoolModule)+}
++++++its+(:to_s)+{+should+eq("dummy")+}
++++end

++++context+"classes"+do
++++++subject+{+dummy_class+}
++++++it+{+should+be_an_instance_of(Class)+}
++++++it+{+defined?(DummyClass).should+be_nil+}
++++++its+(:name)+{+should+eq("DummyClass")+}
++++end
++end

++context+"cntxt2"+do
++++it+"should+not+be+possible+to+access+let+methods+from+anohter+context"+do
++++++defined?(dummy_class).should+be_nil
++++end
++end

++it+"should+not+be+possible+to+access+let+methods+from+a+child+context"+do
++++defined?(dummy_class).should+be_nil
++end
end

#You+could+also+try+to+benefit+from+implicit+subject+using+the+descbie
#method+in+conjunction+with+local+variables.+You+may+want+to+scope+your+local
#variables.+You+can't+use+context+here,+because+that+can+only+be+done+inside
#a+describe+block,+however+you+can+use+Porc.new+and+call+it+immediately+or+a
#describe+blocks+inside+a+describe+block.

#Proc.new+do
describe+"YourCoolModule"+do+#But+you+mustn't+refer+to+the+module+by+the
++#constant+itself,+because+if+you+do,+it+seems+you+can't+reset+what+your
++#describing+in+inner+scopes,+so+don't+forget+the+quotes.
++dummy_class+=+Class.new+{+include+YourCoolModule+}
++#Now+we+can+benefit+from+the+implicit+subject+(being+an+instance+of+the
++#class+whenever+we+are+describing+a+class)+and+just..
++describe+dummy_class+do
++++it+{+should+respond_to(:your_cool_module_method)+}
++++it+{+should_not+be_an_instance_of(Class)+}
++++it+{+should+be_an_instance_of(dummy_class)+}
++++it+{+should+be_a(YourCoolModule)+}
++end
++describe+Object+do
++++it+{+should_not+respond_to(:your_cool_module_method)+}
++++it+{+should_not+be_an_instance_of(Class)+}
++++it+{+should_not+be_an_instance_of(dummy_class)+}
++++it+{+should+be_an_instance_of(Object)+}
++++it+{+should_not+be_a(YourCoolModule)+}
++end
#end.call
end

#In+this+simple+case+there's+necessarily+no+need+for+a+variable+at+all..
describe+Class.new+{+include+YourCoolModule+}+do
++it+{+should+respond_to(:your_cool_module_method)+}
++it+{+should_not+be_a(Class)+}
++it+{+should+be_a(YourCoolModule)+}
end

describe+"dummy_class+not+defined"+do
++it+{+defined?(dummy_class).should+be_nil+}
end|code-block|syntax|javascript|1435507|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1542945/testing-modules-in-rspec#answer-1568024^0|T|4|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

I would suggest that for larger and much used modules one should opt for the "Shared Example Groups" as suggested by @Andrius <a href="https://stackoverflow.com/questions/1542945/testing-modules-in-rspec#answer-1568024">here</a>. For simple stuff for which you don't want to go through the trouble of having multiple files etc. here's how to ensure maximum control over the visibility of your dummy stuff (tested with rspec 2.14.6, just copy and paste the code into a spec file and run it):

<pre><code>module YourCoolModule
 def your_cool_module_method
 end
end

describe YourCoolModule do
 context "cntxt1" do
 let(:dummy_class) do
 Class.new do
 include YourCoolModule

 #Say, how your module works might depend on the return value of to_s for
 #the extending instances and you want to test this. You could of course
 #just mock/stub, but since you so conveniently have the class def here
 #you might be tempted to use it?
 def to_s
 "dummy"
 end

 #In case your module would happen to depend on the class having a name
 #you can simulate that behaviour easily.
 def self.name
 "DummyClass"
 end
 end
 end

 context "instances" do
 subject { dummy_class.new }

 it { subject.should be_an_instance_of(dummy_class) }
 it { should respond_to(:your_cool_module_method)}
 it { should be_a(YourCoolModule) }
 its (:to_s) { should eq("dummy") }
 end

 context "classes" do
 subject { dummy_class }
 it { should be_an_instance_of(Class) }
 it { defined?(DummyClass).should be_nil }
 its (:name) { should eq("DummyClass") }
 end
 end

 context "cntxt2" do
 it "should not be possible to access let methods from anohter context" do
 defined?(dummy_class).should be_nil
 end
 end

 it "should not be possible to access let methods from a child context" do
 defined?(dummy_class).should be_nil
 end
end

#You could also try to benefit from implicit subject using the descbie
#method in conjunction with local variables. You may want to scope your local
#variables. You can't use context here, because that can only be done inside
#a describe block, however you can use Porc.new and call it immediately or a
#describe blocks inside a describe block.

#Proc.new do
describe "YourCoolModule" do #But you mustn't refer to the module by the
 #constant itself, because if you do, it seems you can't reset what your
 #describing in inner scopes, so don't forget the quotes.
 dummy_class = Class.new { include YourCoolModule }
 #Now we can benefit from the implicit subject (being an instance of the
 #class whenever we are describing a class) and just..
 describe dummy_class do
 it { should respond_to(:your_cool_module_method) }
 it { should_not be_an_instance_of(Class) }
 it { should be_an_instance_of(dummy_class) }
 it { should be_a(YourCoolModule) }
 end
 describe Object do
 it { should_not respond_to(:your_cool_module_method) }
 it { should_not be_an_instance_of(Class) }
 it { should_not be_an_instance_of(dummy_class) }
 it { should be_an_instance_of(Object) }
 it { should_not be_a(YourCoolModule) }
 end
#end.call
end

#In this simple case there's necessarily no need for a variable at all..
describe Class.new { include YourCoolModule } do
 it { should respond_to(:your_cool_module_method) }
 it { should_not be_a(Class) }
 it { should be_a(YourCoolModule) }
end

describe "dummy_class not defined" do
 it { defined?(dummy_class).should be_nil }
end
</code></pre>

blocks|key|1220643|text|您还可以使用helper类型|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1220644|#+api_helper.rb
module+Api
++def+my_meth
++++10
++end
end|code-block|syntax|javascript|1220645|#+spec/api_spec.rb
require+"api_helper"

RSpec.describe+Api,+:type+=>+:helper+do
++describe+"#my_meth"+do
++++it+{+expect(+helper.my_meth+).to+eq+10+}
++end
end|1220646|下面是文档：https://www.relishapp.com/rspec/rspec-rails/v/3-3/docs/helper-specs/helper-spec|offset|length|1220647|entityMap|0|LINK|mutability|MUTABLE|url|https://www.relishapp.com/rspec/rspec-rails/v/3-3/docs/helper-specs/helper-spec^0|0|0|0|6|27|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|D|7|W|8|@]|9|@]|A|$E|F]]|$1|I|3|J|5|6|7|X|8|@]|9|@$K|Y|L|Z|1|10]]|A|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|T]]]]

You can also use the helper type

<pre class="lang-rb prettyprint-override"><code># api_helper.rb
module Api
 def my_meth
 10
 end
end
</code></pre>

<pre class="lang-rb prettyprint-override"><code># spec/api_spec.rb
require "api_helper"

RSpec.describe Api, :type =&gt; :helper do
 describe "#my_meth" do
 it { expect( helper.my_meth ).to eq 10 }
 end
end
</code></pre>

Here's the documentation: <a href="https://www.relishapp.com/rspec/rspec-rails/v/3-3/docs/helper-specs/helper-spec" rel="nofollow noreferrer">https://www.relishapp.com/rspec/rspec-rails/v/3-3/docs/helper-specs/helper-spec</a>

blocks|key|1220672|text|您只需在规范文件RSpec.describe+Test::MyModule+do+++include+Test::MyModule+#you+can+call+directly+the+method+*test*+++it+'returns+test'+do+++++expect(test).to+eql('test')+++end+end中将模块包含到规范文件mudule+Test+++module+MyModule+++++def+test+++++++'test'+++++end+++end+end中|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1220673|entityMap^0|8|4J|52|21|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

you need to simply include your module to your spec file
<code>
mudule Test
 module MyModule
 def test
 'test'
 end
 end
end
</code>
in your spec file
<code>
RSpec.describe Test::MyModule do
 include Test::MyModule #you can call directly the method *test*
 it 'returns test' do
 expect(test).to eql('test')
 end
end
</code>

blocks|key|1220723|text|测试独立于包含它们的类的模块方法的一种可能的解决方案|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1220724|module+moduleToTest
++def+method_to_test
++++'value'
++end
end|code-block|syntax|javascript|1220725|并对其进行规范|1220726|describe+moduleToTest+do
++let(:dummy_class)+{+Class.new+{+include+moduleToTest+}+}
++let(:subject)+{+dummy_class.new+}

++describe+'#method_to_test'+do
++++it+'returns+value'+do
++++++expect(subject.method_to_test).to+eq('value')
++++end
++end
end|1220727|如果您想对它们进行干测试，那么shared_examples是一个很好的方法|offset|length|1220728|entityMap|0|LINK|mutability|MUTABLE|url|https://relishapp.com/rspec/rspec-core/v/2-13/docs/example-groups/shared-examples^0|0|0|0|0|F|F|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|10|8|@]|9|@$M|11|N|12|1|13]]|A|$]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

One possible solution for testing module method which are independent on class that will include them

<pre><code>module moduleToTest
 def method_to_test
 'value'
 end
end
</code></pre>

And spec for it

<pre><code>describe moduleToTest do
 let(:dummy_class) { Class.new { include moduleToTest } }
 let(:subject) { dummy_class.new }

 describe '#method_to_test' do
 it 'returns value' do
 expect(subject.method_to_test).to eq('value')
 end
 end
end
</code></pre>

And if you want to DRY test them, then <a href="https://relishapp.com/rspec/rspec-core/v/2-13/docs/example-groups/shared-examples" rel="nofollow noreferrer">shared_examples</a> is good approach

What are the best practices on testing modules in RSpec? I have some modules that get included in few models and for now I simply have duplicate tests for each model (with few differences). Is there a way to DRY it up?

Testing modules in RSpec

在RSpec中测试模块的最佳实践是什么？我有一些模块包含在几个模型中，现在我只是对每个模型都有重复的测试(几乎没有区别)。有没有办法把它弄干？

问在RSpec中测试模块
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在RSpec中测试模块EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在RSpec中测试模块
EN