The Code

Let’s just drop the code in and discuss it afterwards:

# config/sunspot.yml
# copy the test settings into the cucumber environment
test: &TEST
  solr:
    hostname: localhost
    port: 8981
    log_level: WARNING

cucumber:
  <<: *TEST

# features/support/config.rb
# start the Solr server and give it a few seconds to initialize
Sunspot::Rails::Server.start
sleep 5

# make sure that pickle calls #index! on our appropriate models
require File.join(File.dirname(__FILE__), 'pickle')
module Pickle
  module Session

    def create_model_with_sunspot(a_model_name, fields = nil)
      result = create_model_without_sunspot(a_model_name, fields)

      model = model(a_model_name)
      model.index! if model.respond_to?(:index!)

      result
    end
    alias_method_chain :create_model, :sunspot

  end
end

# clean out the Solr index after each scenario
After do
  Post.remove_all_from_index!
end

# shut down the Solr server
at_exit do
  Sunspot::Rails::Server.stop
end

The Details

This method was heavily influenced by Brandon Keeper’s post on using Cucumber with ThinkingSphinx. Thanks Brandon! So in my setup, I’m using Sunspot, Cucumber and Pickle (see Ryan Bates’ railscast on using Pickle with Cucumber for more details on the wonderful Pickle gem).

First and foremost is getting the testing Solr server running. It will look for settings in config/sunspot.yml according to the environment we’re running in, so we need to duplicate the test environment for cucumber. I’ve found that it takes 3-5 seconds for Solr to properly spin up, so we’re sleeping for a few seconds to avoid the problem.

Next we need to ensure that each model gets loaded into Solr’s index when created. If you’re instantiating models on your own, this boils down to calling #index! on any models that you create. Since I’m using Pickle (and didn’t want to rework the included pickle_steps.rb), I needed a bit more invasive measure. A bit of alias_method_chain voodoo lets me call #index! on every instantiated model that responds to it. This ensures that Pickle always adds it’s models to Solr’s index. I was pleased to find that I didn’t have to disable transactional fixtures

Finally, we need to ensure that our index is fresh for each scenario, so we clear the Solr index out after each scenario is run. If you want a more targeted approach, you can use

# features/support/config.rb
# clear Solr index only if we've actually used it
After('@sunspot') do
  Post.remove_all_from_index!
end

to only clear the Solr index after stories which are tagged with @sunspot. Once all the stories are run, shut down the server. Viola!

1. Sunspot includes a development version of Solr

There’s no need to download an official Solr release from Apache for development work. Just install sunspot and you get Solr for free, complete with some nice Rake tasks.

gem install sunspot
rake sunspot:solr:start --starts the solr server
rake sunspot:solr:stop --stops the solr server


2. Using Sunspot in Rails requires the sunspot_rails gem

This one was easy to solve, but still surprised me a bit. The sunspot gem only provides the base interaction with the Solr server. In order to get ActiveRecord integration, you need to add the sunspot_rails gem:

# config/environment.rb
config.gem 'sunspot', :lib => 'sunspot'
config.gem 'sunspot_rails', :lib => 'sunspot/rails'

$ rake gems:install

3. Text Analysis is setup in Solr, not in Sunspot

It seems there’s not much written in the Sunspot documentation/groups about text analysis (such as word stemming, stop word filters, synonyms analysis, etc), and for good reason. These settings are defined in Solr’s setup via the schema.xml file. More details on Solr’s text analysis abilities can be found on Apache’s website. If you’re using the install you get with Sunspot, you can find this in RAILS_ROOT/solr/conf/schema.xml.

4. Sunspot executes its search DSL in a new scope

This one took me forever to figure out. By default, any details passed into Sunspot.search are not evaluated in the current context. This means that trying to search directly from the controller just doesn’t work as I expected. There’s no mention of this in sunspot_rails’ documentation, but there’s a brief snippet in sunspot’s:

If the block passed to search takes an argument, that argument will present the DSL, and the block will be evaluated in the calling context. This will come in handy for building searches using instance data or methods

So, in order to search from the controller (or rather in the model, like you should), you’ll need to pass an argument to the Sunspot.search block:

@search = Sunspot.search(Post) do |query|
query.keywords params[:query]
end