Large 8yqds 91olw alejandro escamilla

Ruby

True Parallel processing for Ruby tests with Flatware

Image 100x100 chris erin Image 100x100 brian dunn

12 minutes to 3 minutes. 20 minutes to 8 minutes. These are a couple of success stories for Flatware. These are test suite times that Flatware reduces by running your tests over multiple processors.

True Parallel processing for Ruby tests

12 minutes to 3 minutes. 20 minutes to 8 minutes. These are a couple of success stories for Flatware. These are test suite times that Flatware reduces by running your tests over multiple processors.

Long test suites plague the lives of many a Ruby on Rails developer. For any project of significant size a massive test suite is needed to verify the correctness of the system. This verification has upside of course, but also a downside. Long test suites kill productivity.

Enter Flatware

Flatware is a long running experiment of Brian Dunn. It uses zeromq to facilitate communication between multiple testing processes and joins the output so that the user sees no difference between running flatware and running rspec or cucumber.

First add the appropriate gems to your Gemfile

group :test do
  gem "flatware-rspec"
  gem "flatware-cucumber"
end

For integration tests, flatware follows a strategy of using a different test database for each potential process. The database.yml file is modified to support a different db connection for each test process with the line:

test:
  database: foo_test<%= ENV['TEST_ENV_NUMBER'] %>

And a precondition to running flatware is preparing each database with the flatware fan command.

flatware fan rake db:test:prepare

A Short Description of how it works

When flatware starts, it spawns one master process and one worker process for each cpu of your computer. The master process determines what files need to be run in the same manner as rspec or cucumber and then distributes the files in a round robin fashion to each of the worker processes. Each worker process then runs the test files in the order they were received and reports back to the master process the status of each test as that test either passes or fails. The master process receives those messages from the worker processes and prints a red or green dot to the screen. When all worker processes have wrapped up their work the report completeness to the master process.

This is the point when flatware provides different functionality from a gem like Parallel. When the master process has received completeness messages from each worker it outputs an end-of-run report that is indistinguishable from what you would see by running rspec or cucumber by itself.

Using ZeroMQ and the specialness of ZeroMQ as a project

ZeroMQ is a unique multiparadigm concurrency framework. It helps facilitate message passing between processes and even between nodes if that is useful for your application. Flatware uses ZeroMQ to move messages between processes in a reliable way.

The ZeroMQ Guide in and of itself is a work of art, with a section entitled Fixing the World that talks about the physics of programming which is well worth a read.

Conclusion

If you are looking to reduce the time of your test suite, please give Flatware a try.

More posts about Ruby