Stubbing out ThinkingSphinx for Rspec

Rails
1

Unless someone advises against it, I don’t want my Rspec suite to be
dependent on having Thinking Sphinx running, as I can often imagine
situations where anyone working on my app would want to run the spec
without the the search engine being powered up. Is there anyway I can
avoid errors like the following;

ThinkingSphinx::ConnectionError in ‘Admin::SitePagesController handling
GET admin/site_pages should render index template’
Connection to Sphinx Daemon (searchd) failed.

Could I stub out the ThinkingSpinx::Connection in the required
controller specs? If so, how do I do this? I’ve tried several methods
but, being a newbie, I haven’t worked it out yet - for example;

controller.stub(ThinkingSphinx::ActiveRecord::Search).and_return(true)

undefined method `to_sym’ for
ThinkingSphinx::ActiveRecord::Search:Module

Any suggestions?

2

in spec helper, overwrite the class that you want to stub
(ThinkingSphinx::ActiveRecord::Search) and stub the method itself.

module ThinkingSphinx::ActiveRecord::Search

def stubbed_method-name
# do nothing
end
end

put it in the spec helper. as this file is loaded before any spec run
(of any file or batch) it will have been the last one to be loaded and
hence will do nothing, but still run your specs.

notice you cannot test any method that uses this module since you have
overridden it completely. so it will help if you want to check the
view renders or your controller does the right thing, but you will not
be able to test the ThinkingSphinx functionallity at all.

On Aug 19, 8:57 pm, Neil C. [email protected]

3

Thanks Wolas!

Sorry if this seems like a newbie question, what am I supposed replace
the stubbed_method_name with?

Also, I came across the only thread on the Interwebs which seems to
cover this topic - it’s over a year old, but I think they have a
solution which could work around the issues you pointed out. However, I
couldn’t work out how to get their subbing approach to work with the way
the ThinkingSphinx syntax looks right now…

Back in the day, they were doing this;

Controller action:

term = “#{params[:search]}”
ThinkingSphinx::Search(term, :with => { :searchable => 1 } })

RSpec example:

it “should build query” do
ThinkingSphinx::Search.should_receive(:search) do |term,conditions|
term.should eql(‘keyword’)
conditions[:with][:searchable].should eql(1)
end
get :show, :search => ‘keyword’
end

But I’m on the latest version of the plugin, and it looks like this;

Controller action:

def index
@site_pages = SitePage.search params[:search]
end

RSpec example:

it “should build query” do
ThinkingSphinx::Search.should_receive(:search) do ?
?
end
get :show, :search => ‘keyword’
end

Any ideas?

http://groups.google.com/group/thinking-sphinx/browse_thread/thread/b879c24ecf06fb12/167f1a92e7d27a72?lnk=gst&q=rspec#167f1a92e7d27a72

“Wolas!” wrote:

in spec helper, overwrite the class that you want to stub
(ThinkingSphinx::ActiveRecord::Search) and stub the method itself.

module ThinkingSphinx::ActiveRecord::Search

def stubbed_method-name
# do nothing
end
end

put it in the spec helper. as this file is loaded before any spec run
(of any file or batch) it will have been the last one to be loaded and
hence will do nothing, but still run your specs.

notice you cannot test any method that uses this module since you have
overridden it completely. so it will help if you want to check the
view renders or your controller does the right thing, but you will not
be able to test the ThinkingSphinx functionallity at all.

On Aug 19, 8:57�pm, Neil C. [email protected]

4

“Wolas!” wrote:

The mocking infrastructure in Rspec-rails is very simple. there are
two ways to “stub” methods:

object.should_receive(:method_name).and_return(whatever)

this is an assertion. it means that the method_name methods HAS to be
called at least once for this test to pass. Also note that the method
itself is never called, so if youre having troubles, just put this
line with the ThinkingSphinx method that is giving you troubles (the
method name you had to replace on my first reply. an example

it ‘should look up the money in the account’ do
@account.should_receive(:money).once # this is our test
@account.balance # here we call
the method that i am testing
end

====
class Account
def balance
self.money.to_f
end
end

in the above example, the “money” method will not actually be called.

the other way is to stub, which means that you are not testing for the
method call, you just want to control the method within a test:

it ‘should look up the money in the account’ do
@account.stub!(:money).and_return(98) # money method will always
return 98
@account.balance.should eql(98) # the test which will
pass
end

in this example the money method is never being called, the testing
framework takes turn and runs its stub.

As a note, you can stub anything, classes instances, arrays, ,…
anything that is an object which in ruby is everything

maybe it doesnt help maybe it does…

good luck

On Aug 20, 7:05�pm, Neil C. [email protected]

Thanks again. You’re too cool. I’m doing this (and it works for me and
my standards);

def do_get
ThinkingSphinx::Search.stub!(:search).and_return(users)
get :index, :search => “bob”
end

5

The mocking infrastructure in Rspec-rails is very simple. there are
two ways to “stub” methods:

object.should_receive(:method_name).and_return(whatever)

this is an assertion. it means that the method_name methods HAS to be
called at least once for this test to pass. Also note that the method
itself is never called, so if youre having troubles, just put this
line with the ThinkingSphinx method that is giving you troubles (the
method name you had to replace on my first reply. an example

it ‘should look up the money in the account’ do
@account.should_receive(:money).once # this is our test
@account.balance # here we call
the method that i am testing
end

====
class Account
def balance
self.money.to_f
end
end

in the above example, the “money” method will not actually be called.

the other way is to stub, which means that you are not testing for the
method call, you just want to control the method within a test:

it ‘should look up the money in the account’ do
@account.stub!(:money).and_return(98) # money method will always
return 98
@account.balance.should eql(98) # the test which will
pass
end

in this example the money method is never being called, the testing
framework takes turn and runs its stub.

As a note, you can stub anything, classes instances, arrays, ,…
anything that is an object which in ruby is everything

maybe it doesnt help maybe it does…

good luck

On Aug 20, 7:05 pm, Neil C. [email protected]