Mule Specs - automated assumption testing

In our last post we talked about mule testing. Assumptions need automation because they’re the foundation our systems are built upon; they can change at anytime. Mule specs are a way to automate mule tests.

You can use any automated testing tool - the one your project already uses is probably fine. Unless it’s QTP. Below is the example from the last post in RSpec using the sequel gem.

describe 'products' do
  it 'do not require a category' do
    sql = <<-SQL
      SELECT count(1) as row_count
      FROM product
      WHERE category IS NULL
    SQL

    at_least_one_row_exists sql
  end
end

We use two helper functions as we phrase our tests to expect either at least one result or no results.

def at_least_one_row_exists sql
  DB[sql][:row_count].should != 0
end

def no_rows_exists sql
  DB[sql][:row_count].should == 0
end

Getting production data

Mule tests require prod data, the older and less realistic it is, the less certainty you have in your assumptions. Running Mule Specs on production data doesn’t mean running them on production, that’s a really bad idea. Copy the data elsewhere before execution. We arranged a sync from production every night and our Mule Specs run against it. So, when we arrive in the morning we know that as of yesterday, all our assumptions are still true.

Mule specs give us more than just a way of verifying assumptions. Written well, with good reporting, you produce verified documentation that’s updated every night when the mules run. Get the entire team involved. Ensure the analysts note their assumptions as they go and have the testers and developers implement them.

Follow your heart, run with the mules every night.