Integration off Rails

Without full stack integration tests I never have complete confidence that a system will function properly. As well tested and designed as the individual components may be there is no way to truly know how they will interact without exercising them together. At its core object orientation is about message passing between objects, and it is the message passing that needs to be tested.

Avoiding Rails

Just recently I revamped Fragmenter, a multipart uploading library that handles storing and reassembling binary data. Fragmenter is designed to work with any web framework, but the most likely targets are Rails applications. Even with such a strong imperative to integration test I still didn't want to test against an entire Rails application.

Simply loading a fresh install of the current Rails (4.0.0 at the time of writing) installs 44 gems, using 33 MB of space, and takes ~1.05 seconds to load:

$ bundle list | wc -l
# 44
$ du -h vendor/ruby/2.0.0 | tail -n 1
# 40M vendor/ruby/2.0.0
$ for i in {1..10}; do time rails r ''; done 2>&1 |\
  awk '{ sum += $4 } END { print sum / NR }'
# 1.05

Fragmenter provides two modules for mixing in to classes within an app, one for models and one for controllers. The modules are insular and only rely on services that Fragmenter provides, they have no reliance on Rails or Railties. The decision to keep Fragmenter decoupled from Rails was made for ease of use with other web frameworks, i.e. Sinatra. Decoupling gives the added benefit of integrating against the most minimal API possible: Any class that can handle Rack requests and responses.

class UploadsController < ApplicationController
  include Fragmenter::Rails::Controller

class Resource < ActiveRecord::Model
  include Fragmenter::Rails::Model

Testing Requests

All of the interaction with Fragmenter's mixins are via HTTP, making it ideal for exercising with a request spec. Using Rack Test makes sending requests to a Rack app and making assertions on the response extremely easy. The standard structure of a request spec looks like:

require 'rack/test'

describe 'A Resource' do
  include Rack::Test::Methods

  let(:app) do
    lambda { [200, {}, 'Success!'] }

  it 'performs a successful GET request' do
    get ''

    expect(last_response).to      eq(200)
    expect(last_response.body).to eq('Success!')

All that Rack::Test expects is an app method returning an object that adheres to the Rack interface. In the example above we have a hardcoded lambda that will always return the same result. To test Fragmenter functionality we'll replace the lambda with a Rack compatible class that includes Fragmenter's controller mixin:

require 'fragmenter/rails/controller'
require 'rack/request'

class UploadsApp
  include Fragmenter::Rails::Controller

  attr_reader :request, :resource

  def initialize(resource)
    @resource = resource

  def call(env)
    @request =

    case request.request_method
    when 'GET'    then show
    when 'PUT'    then update
    when 'DELETE' then destroy

When a Rails controller handles requests it automatically provides the request object. Here we must instantiate the request manually, which is very straight forward. Each of the HTTP verbs is then mapped directly to the corresponding mixed in method—acting as a micro RESTful router.

Lets write a spec to actually test the request/response cycle for one of the UploadApp methods:

require 'fragmenter'
require 'json'
require 'rack/test'

describe 'Uploading Fragments' do
  include Rack::Test::Methods

  Resource = do
    include Fragmenter::Rails::Model

    def rebuild_fragments
      fragmenter.rebuild && fragmenter.clean!

  let(:resource) { }
  let(:app)      { }

  it 'Stores uploaded fragments' do
    header 'Content-Type',      'image/gif'
    header 'X-Fragment-Number', '1'
    header 'X-Fragment-Total',  '2'

    put '/', file_data('micro.gif')

    expect(last_response.status).to eq(200)
    expect(decoded_response).to eq(
      'content_type' => 'image/gif',
      'fragments'    => %w[1],
      'total'        => '2'

    header 'X-Fragment-Number', '2'
    header 'X-Fragment-Total',  '2'

    put '/', file_data('micro.gif')

    expect(last_response.status).to eq(202)
    expect(decoded_response).to eq('fragments' => [])

The example simulates uploading two distinct parts of a very small gif and sets expectations about the responses it gets back. It looks like there is a lot more going on here, but all of the methods (header, put) are still provided by Rack::Test. The most notable addition is the Resource class, a generic model-like class that includes Fragmenter's model mixin.

Running the spec yields an unexpected error:

Failure/Error: put '/', file_data('micro.gif')
 undefined method `render' for #<UploadsApp:0x007fb96c1c2168>

The render method is the missing part of the Rails compatibility puzzle. Each of the controller actions end with a call to render with some json and a status code. Looking through the signature for render it is clear that only need to implement a small part of the functionality to get Rails compatibility with the UploadsApp:

require 'fragmenter'
require 'rack/request'
require 'rack/response'

class UploadsApp
  # No change to the rest of the class


  def render(options)
    body = if options[:json]
    end, options[:status], {}).finish do
      @uploader = nil

The the compatible render method in place our specs pass, and very quickly at that!

Uploading Fragments
  Stores uploaded fragments

Finished in 0.01303 seconds
1 example, 0 failures

A Solid Victory

All of the integration issues exposed by the request spec were between Fragmenter classes and Rack, there weren't any incompatibilities when it was pulled into a full Rails app.

The tradeoff of testing without Rails is that it won't be resistant to changes in render, but that has been stable for a long time. The risk is well worth the savings in setup, boot time, run time, and complexity.

Please note that in reality the spec was written before the UploadApp implementation. It made more sense to explain the process slightly out of order.