Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Testing Ruby Services without Mocks

There seems to be a tendency to stub or mock classes when writing integration tests for basic http services. I’m actually not a big fan of this approach. By definition, the integration test should truly integrate with another subsystem. In the case of a http service, the tests should probably integrate over http, agreed?

Here’s one approach for testing services without stub or mocks…

Imagine a reservation booking system that integrates with a 3rd party API. By default, you might create a Rails model that extends ActiveModel, ActiveRecord or even ActiveResource. Although you stop, after reading this blog post, and create an unbuilt Gem that reaches out to the 3rd party service. Your service might look something like this…

require "rack"
require "nokogiri"

class ReservationService
  def create_reservation(reservation)
    url = URI.parse('http://localhost:9393/')
    http =, url.port)
    response, body =, reservation.to_xml, {'Content-type' => 'text/xml; charset=utf-8'})
    reservation = Reservation.from_xml(body)

More important, your immutable model might look something like this. (Note: I’m not inheriting from a Active* base class, although I’ll save the inheritance discussion for another blog post)

class Reservation
  attr_reader :name, :date, :duration, :booked

  def initialize(name, date, duration, booked = false)
    @name = name
    @date = date
    @duration = duration
    @booked = booked

  def to_xml
    doc = <<XML
<?xml version="1.0" encoding="UTF-8"?>

  def self.from_xml(xml)
    doc = Nokogiri::HTML(xml)
    doc.xpath("//reservation").each do |reservation|
      reservation.children.each do |child|
          when "name"
            @name = child.text
          when "date"
            @date = Date.parse(child.text)
          when "duration"
            @duration = child.text.to_i
          when "booked"
            @booked = eval(child.text)
    end, @date, @duration, @booked)

Then you start writing tests. You stub the service, then you stub Typhoeus. You might pull Typhoeus and use Artifice or rack-test. Sure the approach works, although are you really testing the full integration (they do stub at the lowest level)?

You could argue a more complete integration test might include the http layer. One approach might be to fire up a simple rack handler that matches the API specification.

Here’s an example…

require "test/unit"
require "date"

require File.expand_path(File.join(File.dirname(__FILE__), "reservation_service"))

class TestServer
  def initialize(response_code, response_body, response_headers = {})
    @response_code = response_code
    @response_body = response_body
    @response_headers = response_headers

  def start
    @thread = do, :Port => "9393", :Host => "localhost")
    sleep 1
    puts "started server."

  def stop
    puts "stopped server."

  def call(env)
    [@response_code, @response_headers, [@response_body]]

class TestService < Test::Unit::TestCase
  def test_create_reservation
    expected_reservation ="John Brown",, 3, true)

    server =, expected_reservation.to_xml, {})

    service =
    actual_reservation = service.create_reservation("John Brown",, 3))

    assert_equal(expected_reservation.duration, actual_reservation.duration)
    assert_equal(expected_reservation.booked, actual_reservation.booked)


(Typhoeus actually uses a similar approach via TyphoeusLocalhostServer.rb within their own test suite)

You might ask why not just integrate with the 3rd party’s API sandbox environment. Because doing so could impact test performance as well as your ability to run tests – you become too dependent on their service’s availability.

A similar approach might be to VCR, although VCR might not work without an actual sandbox environment.

  1. Joe Van Dyk says:

    No no no no… you want to use VCR.

  2. urrtlopserty
    Shiny lilac suede sewn light household leather is often identical, nevertheless applying dense pattern, even so the hindfoot is usually supplied from the teeny laces intended for beautification; Shoelace continues to position hole, light curtains a compact document, the main points usually are generally gentle.

  3. iioopprrtteeww
    The particular reddish dots inside white-colored buckskin foundation, regular sewing buckskin shade, the particular automobile accident regarding delightful and also attractive. The particular transforming type high heels helps it be thus captivating in which it is able to bring in every person. The particular dip inside the tiny department of transportation features a got in, and in addition along with a great attractive bohemian. Can be found in the particular useless get more entertaining to be able to shade lock up and also increase more details to be able to Isabel Marant shoes or boots beautification.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *

Share This