Flatware parallelizes your test suite to significantly reduce test time.
- ZeroMQ > 4.0
sudo apt-get install -qq libzmq3-dev
(Never you mind the 3. This package contains ZMQ version 4.)
If you're on macOS 10.12, use the custom hashrocket ZMQ homebrew formula.
brew tap hashrocket/formulas brew install hashrocket/formulas/zeromq
The stock homebrew version will likely work on older versions of macOS.
brew install zeromq
Add the runners you need to your Gemfile:
gem 'flatware-rspec', require: false # one gem 'flatware-cucumber', require: false # or both
To run your entire suite with the default cucumber options, add the
flatware-cucumber gem and just:
$ flatware cucumber
To run your entire suite with the default rspec options add the
flatware-rspec gem and just:
$ flatware rspec
The rspec runner can balance worker loads, making your suite even faster.
It forms balaced groups of spec files according to their last run times, if you've set
example_status_persistence_file_path in your RSpec config.
For this to work the configuration option must be loaded before any specs are run. The
.rspec file is one way to achive this:
But beware, if you're using ActiveRecord in your suite you'll need to avoid doing things that cause it to establish a database connection in
spec_helper.rb. If ActiveRecord connects before flatware forks off workers, each will die messily. All of this will just work if you're following the recomended pattern of splitting your helpers into
If you'd like to limit the number of forked workers, you can pass the 'w' flag:
$ flatware -w 3
Additionally, for either cucumber or rspec you can specify a directory:
$ flatware rspec spec/features
Typical Usage in a Rails App
Add the following to your
test: database: foo_test
test: database: foo_test<%=ENV['TEST_ENV_NUMBER']%>
Run the following:
$ rake db:setup # if not already done $ flatware fan rake db:test:prepare
Now you are ready to rock:
$ flatware rspec && flatware cucumber
- Use heuristics to run your slowest tests first
- Fully test at an integration level. Don't be afraid to change the code. If you break it you'll know.
- Couple as loosely as possible, and only to the most stable/public bits of Cucumber and RSpec.
- Projects define their own preparation scripts
- Only distribute to local cores (for now)
- Depend on a dedicated messaging library
- Be accountable for completed work; provide progress report regardless of completing the suite.
Flatware integration tests use aruba. In order to get a demo cucumber project you
can add the
@no-clobber tag to
features/flatware.feature and run the test
cucumber features/flatware.feature. Now you should have a
directory. CD there and
flatware will be in your path so you can tinker away.
How it works
Flatware relies on a message passing system to enable concurrency. The main process declares a worker for each cpu in the computer. Each worker forks from the main process and is then assigned a portion of the test suite. As the worker runs the test suite it sends progress messages to the main process. These messages are collected and when the last worker is finished the main process provides a report on the collected progress messages.
To learn more about the messaging system that Flatware uses, take a look at the excellent ZeroMQ guide.
Contributing to Flatware
Do whatever you want. I'd love to help make sure Flatware meets your needs.