Testing and Local Development Using Split’s Off-the-Grid Mode

This blog post will try to shine some light on the recently added support for local development as well as how to integrate Split into your continuous build and unit testing.

We’ll walk you through the creation of a demo app and how to run unit tests with Split by setting the expected behavior with a specific file in the path (we call it off-the-grid mode).

Create a Demo App in Ruby

Let’s start with creating a rails app from the ground up: rails new splitio-test

Don’t forget to add the splitclient-rb gem to your brand new Gemfile, then run bundle install.

Configure Feature Flags

To configure the Split SDK you’ll need to create an initializer. The file config/initializers/splitclient.rb should look like this:

factory = SplitIoClient::SplitFactoryBuilder.build(
  path: '/path/to/splitio-test/config/split',
  reload_rate: 3

Rails.configuration.split_client = factory.client
Rails.configuration.split_manager = factory.managerCode language: Elixir (elixir)

A brief description of the two parameters passed above:

  • path required : the absolute path to the split file (more on that below)
  • reload_rate optional : the SDK can refresh features from the split file (it doesn’t do so by default); here you can specify the reload rate in seconds.


Let’s generate a sample WelcomeController with one action, indexrails g controller welcome index

We also need to create the Split file. It can be located anywhere in the system, but for the sake of this tutorial let’s put it in the config/ folder.

Make sure you include the full path to the file in the splitclient.rb initializer.

In your welcome_controller.rb:

def index
  @treatment = Rails.application.config.split_client.get_treatment('', params[:feature] || '')
endCode language: Ruby (ruby)

And in the views/welcome/index.html.erb:

<p>Treatment for the feature <%= params[:feature] %> is <%= @treatment %></p>Code language: Django (django)

Put It All Together

Now we can start our Rails server by running rails s. When you visit http://localhost:3000/welcome/index?feature=awesome_feature you should see:

Treatment for the feature awesome_feature is on

And when you visit http://localhost:3000/welcome/index?feature=not_so_awesome_feature, you should expect to see:

Treatment for the feature awesome_feature is off

Any other feature name, which is not specified in the Split file should return control.

Changes Picked Up Automatically

Just as developers make changes to their application and expect them to appear without refreshing the app, Split’s off-the-grid mode supports exactly the same use case. Any changes made to the split file will be picked up in reload_rate seconds and the Split SDK will return the newly changed treatments, thus, providing a more interactive development experience without the need to reload your application server.


Let’s write a test to make sure everything works as expected based on the content of our split off-the-grid mode file.

Firstly, add the rspec-rails gem to the Gemfile, and then generate the WelcomeController spec.

Inside splitio-test/spec/controllers/welcome_controller_spec.rb we’ll write couple of specs:

# spec/controllers/welcome_controller_spec.rb

it 'sets on treatment for awesome_feature' do
  get :index, feature: 'awesome_feature'

  expect(assigns(:treatment)).to eq('on')

it 'sets on treatment for awesome_feature' do
  get :index, feature: 'not_so_awesome_feature'

  expect(assigns(:treatment)).to eq('off')

it 'sets on treatment for awesome_feature' do
  get :index, feature: 'random_feature'
  expect(assigns(:treatment)).to eq('control')
endCode language: Elixir (elixir)

The test is expecting three things:

  1. We expect to get the on treatment for the awesome_feature.
  2. We expect to get the off treatment for the not_so_awesome_feature.
  3. We expect to get the control treatment on the random_feature, which was not listed inside the Split configuration file.

The Results

Now run bundle exec rspec spec/controllers/welcome_controller_spec.rb

All three specifications should be green.

Wrap up

Split provides off-the-grid capabilities to perform split evaluations disconnected from our backend. The immediate consequence of that is that ability to perform unit tests without needing to do any remote calls to Split backend, as the treatments are stored in a file. This technique can be utilized for quick development as well as unit testing. For more sophisticate testing consider defining different configuration scenarios, each of them represented by a specific split off-the-grid file, and switching them in the Before section of your unit tests.