On Sat, Jan 15, 2011 at 9:40 PM, Lille <[email protected]> wrote:
> I guess I depart from the BDD line, because I feel that if I test a
> module and I test that the host implements it when expected, then that
> should be enough. For example, if I have a module whose single method
> has four possible results and then I implement it in 4 hosts, I might
> have to have as much as 16 tests versus my approach's 8,
> alternatively.
(snip)
> Of course, it seems like testing the invocations of the module has no
> facility in RSpec, due, perhaps, to the BDD approach, which, I allow,
> I may come to see as wiser, with more experience.
RSpec provides easy access to message expectations for things like that.
In the case of a single module included in several places, I would
probably specify the behavior in one place (either directly against
the model, or using a fake wrapper if necessary), and then use a
message expectation to check that you've hooked everything up. E.g.:
require 'spec_helper'
class FilterTesterController < ApplicationController
before_filter :some_filter, :only => [:wrap_some_filter]
def wrap_some_filter
# whatever
end
end
describe FilterTesterController, "#some_filter" do
before(:each) do
MyApp::Application.routes.draw do
get :wrap_some_filter, :to => 'filter_tester#wrap_some_filter',
:as => 'originating'
end
end
after(:each) do
MyApp::Application.reload_routes!
end
it "does what I expect it to" do
get :wrap_some_filter
# expectation
end
end
describe "One or all of your other classes that include the module" do
it "is hooked up" do
YourModule.should_receive(:the_method).with :some_params
get :some_action # or YourClass.new.some_method or whatever
end
end
Cheers,
Katrina
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
