Ruby performance testing tips and tricks

This post comes to us from our friends and partners at thoughtbot, a leading provider of Ruby on Rails based web application development and training services. Many thanks to Jason Morrison, Matt Jankowski, Dan Croak and Nick Quaranto from the thoughtbot team for pulling this together.

Use em_proxy to load-test code changes

By Jason Morrison

Running a high-traffic site with little room for downtime could make deploying large changes daunting. What if your new code has a large impact on performance?

We’ve been in this situation several times with Hoptoad as we make large changes and improvements to the codebase. Things like changing databases, upgrading major versions of Rails, and adding queueing can have unpredictable effects on performance. Little things can have a big effect, too, when most of your traffic is focused in one write-heavy API endpoint.

We’ve boosted our confidence in rolling out these changes by performance testing ahead of time. We’ve tried a variety of synthetic load testing approaches, but the most realistic way to do this is by using real traffic.

We use Ilya Grigorik’s em-proxy to fork traffic in real time from our production environment to a load testing environment which is identical save for the new code. (See the duplex. rb example in em-proxy). We use Engine Yard’s “Clone Environment” feature to make a reasonably up-to-date copy of production, and we use a Chef recipe to toggle em-proxy on and off. We use New Relic RPM to keep an eye on performance, and make sure that the load testing environment performance is acceptable. Once we’ve run a few hours to a day’s worth of traffic, we’ll shut down the load testing environment, and deploy the change live.

Automatic cucumber step generation with factory girl

By Dan Croak

Did you know that Factory Girl includes some steps for your integration testing pleasure? They are currently

available but remain relatively unknown.

Let’s assume you’ve defined your factories normally in test/factories. rb or spec/factories. rb:

Factory. define :user do |user|
user. email { Factory. next(:email) }
user. password { “password” }
user. password_confirmation { “password” }
End

Factory. define :author, :parent => :user do |author|
author. after_create { |a| Factory(:article, :author => a) }
End

Factory. define :recruiter, :parent => :user do |recruiter|
recruiter. is_recruiter { true }
End
Once those are in place, and assuming you’ve otherwise loaded factory girl correctly, add this to features/support/env. rb:

Require ‘factory_girl/step_definitions’
Then, write Cucumber features using the simple “create record” step:

Given a user exists
…or the “create record & set one attribute” step:

Given an author exists with an email of “author@example. com”
…or the “create record & set multiple attributes” step:

Given the following recruiter exists:
| email | phone number | employer name |
| bill@example. com | 1234567890 | thoughtbot |
These steps will be available for all your factories, so stop writing boilerplate steps and shake what Factory Girl gave you.

(Testbot * Fog) + Hudson = Faster Tests!

By Nick Quaranto

Test suites can get slow, even when running on one high powered machine. So why not spin up EC2 instances and distribute the tests?

This is made really easy with testbot, a distributed test runner. It works like so:

A requester kicks off the process, asking for tests to be run