It is common for web applications to interface with external services. When testing, since depending on an external service is very fragile, we end up mocking the interaction with such services. However, once in a while, it is still a good idea to check if the contract between your application and the service is still valid.

For example, this week we had to interact with a SOAP service, let’s call it KittenInfo (why would someone provide kitten information via a SOAP service is beyond the scope of this blog post). We only need to contact one end-point of the KittenInfo and it is called get_details, which receives a kitten identifier and returns kitten information:

KittenInfo::Client.new.get_details("gorbypuff")

Since this API is simple, it is very easy to mock the client whenever it is required by our application. On the other hand, we still need to verify that the integration between KittenInfo SOAP service and our application works correctly, so we write some tests for it:

describe KittenInfo::Client do
  it "retrieves kitten details" do
    client  = KittenInfo::Client.new
    details = client.get_details("gorbypuff")
    details[:owner].should == "tenderlove"
  end
end

However, since this is actually contacting the SOAP Service, it may make your test suite more fragile and slower, even more in this case, in which the SOAP Service responses take as long as kitten’s staring contests.

One possible solution to this problem is to make use of filter tags to exclude the SOAP integration tests from running, except when explicitly desired. We could do this by simply setting:

describe KittenInfo::Client, external: true do
  # ...
end

Then, in your spec_helper.rb, just set:

RSpec.configure do |config|
  config.filter_run_excluding external: true
end

Now, running your specs will by default skip all groups that have :external set to true. Whenever you tweak the client, or in your builds, you can run those specific tests with:

$ rspec --tag external

Notice that filter mechanism is similar to how we enable JavaScript tests when using Capybara. This means that, when using Capybara, you could also run all JavaScript tests in your app via $ rspec --tag js or all non-JavaScript tests with $ rspec --tag ~js.

What about you? What is your favorite RSpec trick?

Tags:

This entry was posted on Thursday, October 25th, 2012 at 11:05 am and is filed under English. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

  • http://twitter.com/cfcosta_ Cainã Costa

    You can add this flag to automatically convert symbols to hash with true values, so you can create an example like this:

    RSpec.configure do |c|
    c.treat_symbols_as_metadata_keys_with_true_values = true
    end

    it “works”, :focus do
    should be_nice
    end

    You can also add a name to your subject:

    subject(:serializer) { Serializer.new(foo) }

    it “serializes” do
    expect(serializer).to be_serializable # this works
    should be_serializable # this too!
    end

    And I really like this “should something” syntax.

  • http://twitter.com/johnbeynon John Beynon

    Why would you not use something like VCR to store the SOAP response so you don’t have to hit the external service in your tests?

  • http://blog.plataformatec.com.br/ josevalim

    John Beynon, the goal of the tests above is to actually hit the server since once in a while to guarantee the contract between the application and the external service is still valid.

    That said VCR is still a good option since it allows you to hit the server by simply cleaning up the cassettes cache and SOAP can be used over HTTP. But depending on the type of external service, you don’t have automatic tools like VCR, so the tip above is still handy.

  • http://blog.plataformatec.com.br/ josevalim

    Thanks for sharing!