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),
> below:
>
> 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
> redirection.
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
post :the_action
response.should redirect_to("other")
end
end
end
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.
Cheers,
David
>
> Thanks,
>
> Lille
>
> On Jan 15, 12:29 am, Nick <[email protected]> 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
>>> filters.
>>
>> 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
>> end
>>
>> Class Foo
>> include Bar
>>
>> def something
>> baz
>> end
>> end
>>
>> f = Foo.new
>> f.should_receive(:baz).and_return nil
>> f.something
>>
>> In the rest of your specs, it's just a matter of stubbing out the call to
>> "baz".
>>
>>> 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!
>> Nick
>>
>> _______________________________________________
>> rspec-users mailing list
>> [email protected]http://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/rspec-users
Cheers,
David
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
