[rspec-users] [rspec-rails] how to test module behavior once and then confirm that controllers implement it?
dchelimsky at gmail.com
Sat Jan 15 13:34:18 EST 2011
On Jan 15, 2011, at 9:45 AM, Lille wrote:
> Thanks Nick, that was helpful.
> I'm wondering if it's possible to test module behavior and then test
> that the module behavior of interest is invoked from the before/after
> filter enclosing the controller action under test.
> To me, it seems that I'm missing a step if I don't fill in my 4),
> 1) test included module behavior
> 2) test that module is included in controller class
> 3) test that the module methods are responsive from the host class
> 4) [test that the module method(s) invoked in before/after filters for
> actions in the host are called when their enclosed actions are.]
> Maybe it would be helpful to note that my module behavior is
Then _that_ ^^ is what you want to specify!!!!!!!!!!! Not 1 or 2. Maybe 3 and/or 4, but they are expressed in very procedural/structural ways.
Paraphrasing myself from The RSpec Book: BDD is about behavior, not structure. It is about what code _does_, not what code _is_.
In this case, the behavior is:
Given these conditions
When I visit one page
Then I should be redirected to other page
Expressed in RSpec:
describe SomeController do
describe "the action" do
context "in some context" do
Please give http://blog.davidchelimsky.net/2010/11/07/specifying-mixins-with-shared-example-groups-in-rspec-2/ a read and let us know if you agree/disagree with the approach.
> On Jan 15, 12:29 am, Nick <n... at deadorange.com> wrote:
>> Hey Lille.
>>> Specifically, what is the recommended structure for the test of the
>>> module filter;
>> How about creating a shared example group, and referencing that?http://blog.davidchelimsky.net/2010/11/07/specifying-mixins-with-shar...
>>> next, how can I confirm that the controller classes
>>> that have included the module and are properly calling its methods as
>> You can check if a class included a module like this:
>> Foo.should include Bar
>> When an object calls a method that was mixed in, the method's called as
>> though it truly is a part of the class. So you can just do:
>> Module Bar
>> def baz; end
>> Class Foo
>> include Bar
>> def something
>> f = Foo.new
>> f.should_receive(:baz).and_return nil
>> In the rest of your specs, it's just a matter of stubbing out the call to
>>> Cracking this could save me from duplicating the testing of the full
>>> behavior of the filters in several instances, in several
>>> ActionController classes.
>> I hope that helps!
>> rspec-users mailing list
>> rspec-us... at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> rspec-users mailing list
> rspec-users at rubyforge.org
More information about the rspec-users