Multi-Engine Rails 3.2 Testing Tips & Tricks, Part 3

This is a continuation of my second post on setting up a CI server for a multi-engine rails 3.2 application.

Use `Pry.rescue {}` For Dynamic `binding.pry`

Getting access to an interactive REPL is essential when debugging a web application. Better Errors does a great job when when interacting with the app directly (in rails4 this functionality comes built in). binding.pry is a great tool when interacting with your code directly in your development or testing environment.

However, there are some cases where adding binding pry to just the right place is either painful or would require you to modify a external gem. An easy way to get around this is to use pry-rescue which will open a pry REPL wherever an exception occurs. This is especially helpful for debugging rake tasks.

Run Rails Server in Test Environment to Debug Hard-to-Replicate Issues

Sometimes I’ve run into issues that I can’t reproduce in development or staging. It’s been helpful to startup a rails server using the test environment to debug issues outside of the content of a specific spec:

bundle exec rails s -e test

# if you have a test_app
cd spec/dummy
bundle exec rails s -e test

Use Test Server Static Port Assignment for Absolute URL Dependent Functionality

If you use premailer with a CSS stylesheet, the external stylesheet reference must be absolute (at least, in the version of premailer the app is using).

Additionally, sometimes there is functionality which require the host name of the app to be set via a configuration preference (e.g. Spree Commerce with Spree::Config.set(:site_url, "domain.com")).

Capybara defaults to starting up a testing web server on a random port. This causes issues if you need to set a site wide configuration preference: you don’t know what the port is until the server is running.

I’ve found it helpful to set Capybara to use consistent port:

Capybara.server_port = 8081

Take a Screenshot of Feature Test State on Failure

Use capybara-screenshot to save a screenshot of what the page looked like that triggered the error. In addition to a PNG, a HTML file is also generated. I’ve found this to be very helpful in debugging feature tests.

# spec_helper.rb

# disable by default
Capybara::Screenshot.autosave_on_failure = false

RSpec.configure do |c|
  c.before(:each, type: :feature) do
    Capybara::Screenshot.autosave_on_failure = example.metadata[:screenshot]
  end
end

Check out this article for more information.

Increase Capybara Wait Time

In my testing enviornment I run all delayed jobs synchronously in order to test the results of backgrounded operations. This means that requests sometimes have to wait on slow external services or connections. Without increasing the default timeout setting, you’ll get errors from capybara:

Capybara.default_wait_time = 10

Nil Out User Generated Paper Clip File Upload References

Some of the seed data I extracted from the live application had paperclip attachment data. Here’s how to wipe it out quickly:

# seeds.rb
Spree::Asset.update_all attachment_file_name: nil, attachment_content_type: nil, attachment_file_size: nil, attachment_width: nil, attachment_height: nil

If you need an image in place, set a default image:

# spec_helper.rb
Spree::Image.attachment_definitions[:attachment][:default_url] = "http://placehold.it/460x260"

Dotenv

If you have unit tests in your applications’ engines repositories, and you are using the 12 factor app structure, you are going to need to load the .env file from the parent directory.

# sub_engine/spec/spec_helper.rb
if ENV['CIRCLECI'].nil? || ENV['CIRCLECI'] != 'true'
  require 'dotenv'
  Dotenv.load! '../.env'
end