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 <n...@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
>>> 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
>> rspec-us...@rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Cheers,
David



_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to