4 minute read
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(
'localhost',
path: '/path/to/splitio-test/config/split',
reload_rate: 3
)
Rails.configuration.split_client = factory.client
Rails.configuration.split_manager = factory.manager
Code 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.
Usage
Let’s generate a sample WelcomeController
with one action, index: rails 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] || '')
end
Code 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
ison
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
isoff
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.
Testing
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')
end
it 'sets on treatment for awesome_feature' do
get :index, feature: 'not_so_awesome_feature'
expect(assigns(:treatment)).to eq('off')
end
it 'sets on treatment for awesome_feature' do
get :index, feature: 'random_feature'
expect(assigns(:treatment)).to eq('control')
end
Code language: Elixir (elixir)
The test is expecting three things:
- We expect to get the
on
treatment for theawesome_feature
. - We expect to get the
off
treatment for thenot_so_awesome_feature
. - We expect to get the
control
treatment on therandom_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.