Integration testing with Cucumber, RSpec and Thinking Sphinx
Ideally you would want to include sphinx in your integration tests. It’s really just like your database. In practice, this is problematic. Ensuring the DB is started and triggering a re-index after each model load is doable, if slow, with a small bit of hacking of thinking sphinx (hint – change the initializer for the ThinkingSphinx::Configuration to allow you to specify the environment). Here’s the rub though – if you’re using transactional fixtures the sphinx indexer won’t be able to see any of your data! Turning that off can really slow down your tests, and once you add in the re-indexing time you’re going to be making a few cups of coffee while they run.
One approach I’ve been taking is to stub out the search methods with RR. I know, I know, stubbing in your integration tests is evil. I’m being pragmatic here. For most applications your search is trivial (find me results for this keyword), and if you unit test your define_index block you’re pretty well covered. To go one step further you could unit test your controllers with an expect on the search method, or have a separate suite of non-transactional integration tests running against sphinx. I like the latter, but haven’t done it yet.
Enough talk! Here’s the magic you need to get it working with cucumber:
1 2 3 4 5 6 7 8 9 |
# features/steps/env.rb require 'rr' Cucumber::Rails::World.send(:include, RR::Adapters::RRMethods) # features/steps/*_steps.rb Given /a car with model '(\w+)' exists/ do |model| car = Car.create!(:model => model) stub(Car).search(model) { [car] } end |
December 23, 2008 at 6:43 AM
I highly advise against stubbing out your search methods at this level of testing. I broke my search features out into a separate suite with a "Before" hook to clean out the database and an "AfterStep" hook to re-index after each step. Indexing takes a fraction of a second because very few models get created for each run. I re-used code from the Sphinx unit tests themselves for detecting if the server is running and starting/restarting it.
It really wasn't much work, and if the tests run slower than my other suites, it isn't noticeable. Definitely worth it to know you're features are being tested end-to-end if you ask me.
December 24, 2008 at 1:21 PM
From the post:
"For most applications your search is trivial (find me results for this keyword), and if you unit test your define_index block you’re pretty well covered."
Increased complexity to get sphinx to work with my tests does not help increase my confidence in my code. If I was doing thing things like geo-search that rely on sphinx, I would revisit.
If you're really interested in end-to-end testing, this approach still misses front end stuff like JS.