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

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
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 = Net::HTTP.new(url.host, url.port)
    response, body = http.post(url.path, reservation.to_xml, {'Content-type' => 'text/xml; charset=utf-8'})
    reservation = Reservation.from_xml(body)
    reservation
  end
end

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
  end

  def to_xml
    doc = <<XML
<?xml version="1.0" encoding="UTF-8"?>
<reservations>
  <reservation>
    <name>#{@name}</name>
    <date>#{@date}</date>
    <duration>#{@duration}</duration>
    <booked>#{@booked}</booked>
  </reservation>
</reservations>
XML
    doc
  end

  def self.from_xml(xml)
    doc = Nokogiri::HTML(xml)
    doc.xpath("//reservation").each do |reservation|
      reservation.children.each do |child|
        case child.name
          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
      end
    end
    Reservation.new(@name, @date, @duration, @booked)
  end
end

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
  end

  def start
    @thread = Thread.new do
      Rack::Handler::WEBrick.run(self, :Port => "9393", :Host => "localhost")
    end
    sleep 1
    puts "started server."
  end

  def stop
    Thread.kill(@thread)
    puts "stopped server."
  end

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

class TestService < Test::Unit::TestCase
  def test_create_reservation
    expected_reservation = Reservation.new("John Brown", Date.today, 3, true)

    server = TestServer.new(200, expected_reservation.to_xml, {})
    server.start

    service = ReservationService.new
    actual_reservation = service.create_reservation(Reservation.new("John Brown", Date.today, 3))

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

    server.stop
  end
end

(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.

Comments
  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 *