Ruby Forum Ruby on Rails > Stubbing out ThinkingSphinx for Rspec

Posted by Neil Cauldwell (neil)
on 19.08.2008 21:57
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?
Posted by "Wolas!" (Guest)
on 20.08.2008 12:47
(Received via mailing list)
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 Cauldwell <rails-mailing-l...@andreas-s.net>
Posted by Neil Cauldwell (neil)
on 20.08.2008 20:05
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 Cauldwell <rails-mailing-l...@andreas-s.net>
Posted by "Wolas!" (Guest)
on 21.08.2008 11:55
(Received via mailing list)
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 Cauldwell <rails-mailing-l...@andreas-s.net>
Posted by Neil Cauldwell (neil)
on 21.08.2008 12:54
"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 Cauldwell <rails-mailing-l...@andreas-s.net>


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