Don't Stub the System Under Test

Don't Stub the System Under Test

xUnit Test Patterns defines the System Under Test (SUT) as:

whatever class, object or method we are testing; when we are writing customer tests, the SUT is probably the entire application or at least a major subsystem of it.

The System Under Test helps us focus on what we’re really testing, what Depended-On Components (DOC) interact with it, and how to replace a Depended-On Component with a Test Double (such as a stub, spy, or fake).

However, it can be tempting to also stub parts of the System Under Test. This should be avoided.

Why not stub the System Under Test?

The goal of the guideline “Don’t Stub the System Under Test” is to help us use tests as a guide for when to split up a class. If a behavior is so complicated that we felt compelled to stub it out in a test, that behavior is its own concern that should be encapsulated in a class.

Example

Let’s say you’re test-driving the client library for a credit card processing gateway. You start with a basic test case for the CreditCard class:

describe CreditCard, '#create_charge' do
  it 'returns transaction IDs on success' do
    body = { 'transaction_id' => '1234' }.to_json
    stub_request(:post, 'payments.example.com/cards/4111/charges').
      to_return(body: body)
    credit_card = CreditCard.new('4111')

    result = credit_card.create_charge(100)

    expect(result.transaction_id).to eq('1234')
  end
end

The implementation:

class CreditCard
  def initialize(id)
    @id = id
  end

  def create_charge(amount)
    response = Net::HTTP.start('payments.example.com') do |http|
      request = Net::HTTP::Post.new("/cards/#{@id}/charges")
      request.body = { 'amount' => amount }.to_json
      http.request(request)
    end

    data = JSON.parse(response.body)
    Response.new(transaction_id: data['transaction_id'])
  end
end

Now that we can place charges, we need to be able to refund them. The test looks familiar:

describe CreditCard, '#refund_charge' do
  it 'returns transaction IDs on success' do
    body = { 'transaction_id' => '2345' }.to_json
    stub_request(:post, 'payments.example.com/cards/4111/charges/1234/refund').
      to_return(body: body)
    credit_card = CreditCard.new('4111')

    result = credit_card.refund_charge('1234')

    expect(result.transaction_id).to eq('2345')
  end
end

The implementation for #refund_charge looks similar to #create_charge:

def refund_charge(transaction_id)
  response = Net::HTTP.start('payments.example.com') do |http|
    request =
      Net::HTTP::Post.new("/cards/#{@id}/charges/#{transaction_id}/refund")
    http.request(request)
  end

  data = JSON.parse(response.body)
  Response.new(transaction_id: data['transaction_id'])
end

We can’t stand this kind of duplication. So, it’s time to extract a method for the common logic. We start by writing a test for a common, private method:

describe CreditCard, '#create_transaction' do
  it 'performs JSON POST requests' do
    request = { 'request' => 'body' }
    response = { 'transaction_id' => '1234' }
    stub_request(:post, 'payments.example.com/example_path').
      with(body: request.to_json)
      to_return(body: response.to_json)
    credit_card = CreditCard.new('4111')

    result = credit_card.send(:create_transaction, '/example_path', request)

    expect(result.transaction_id).to eq('2345')
  end
end

Next, we implement that method:

private

def create_transaction(path, data = {})
  response = Net::HTTP.start('payments.example.com') do |http|
    post = Net::HTTP::Post.new(path)
    post.body = data.to_json
    http.request(post)
  end

  data = JSON.parse(response.body)
  Response.new(transaction_id: data['transaction_id'])
end

We can expect a call to this method in our tests:

describe CreditCard, '#create_charge' do
  it 'returns transaction IDs on success' do
    expected = stub('expected')
    credit_card.
      stub(:create_transaction).
      with('/cards/4111/charges/1234/refund', amount: 100).
      and_return(expected)
    credit_card = CreditCard.new('4111')

    result = credit_card.create_charge(100)

    expect(result).to eq(expected)
  end
end

Then we can use the method in our class:

def create_charge(amount)
  create_transaction("/cards/#{@id}/charges", amount: amount)
end

We can then create a similar stub for #refund_charge. No more duplication!

However, things have gone a little wrong: we’re not listening to our tests. The need to stub out a private method in our SUT tells us there’s a concern to be encapsulated: formatting and transmitting requests to our gateway server.

Let’s extract that concern.

First, we’ll move our tests for the private method over to a new Client class test:

describe Client, '#post' do
  it 'performs JSON POST requests' do
    request = { 'request' => 'body' }
    response = { 'transaction_id' => '1234' }
    stub_request(:post, 'payments.example.com/example_path').
      with(body: request.to_json)
      to_return(body: response.to_json)
    client = Client.new

    result = client.create_transaction('/example_path', request)

    expect(result.transaction_id).to eq('2345')
  end
end

We can copy the code over from #create_transaction:

class Client
  def post(path, data = {})
    response = Net::HTTP.start('payments.example.com') do |http|
      post = Net::HTTP::Post.new(path)
      post.body = data.to_json
      http.request(post)
    end

    data = JSON.parse(response.body)
    Response.new(transaction_id: data['transaction_id'])
  end
end

Then, we’ll change our test to inject a stubbed dependency:

describe CreditCard, '#create_charge' do
  it 'returns transaction IDs on success' do
    expected = stub('expected')
    client = stub('client')
    client.
      stub(:post).
      with('/cards/4111/charges/1234/refund', amount: 100).
      and_return(expected)
    credit_card = CreditCard.new(client, '4111')

    result = credit_card.create_charge(100)

    expect(result).to eq(expected)
  end
end

Next, we’ll change our class to accept and use that dependency:

class CreditCard
  def initialize(client, id)
    @client = client
    @id = id
  end

  def create_charge(amount)
    @client.post("/cards/#{@id}/charges", amount: amount)
  end

  def refund_charge(transaction_id)
    @client.post("/cards/#{@id}/charges/#{transaction_id}/refund")
  end
end

By avoiding a stub on the SUT, we discovered that we can cleanly split our class into two: one class to handle the high level details of which requests to make for semantic actions like creating charges, and another class which knows how to translate those actions into HTTP requests.

How to avoid stubbing the System Under Test

Each time I’m tempted to stub the SUT, I think about why I didn’t want to set up the required state.

If extracting a helper or factory to set up the state wouldn’t be ugly or cause other issues, I’ll do that and remove the stub.

If the method I’m stubbing has complicated behavior that’s aggravating to retest, I use that as a cue to extract a new class, and then I stub the new dependency.

What’s next?

If you found this useful, you might also enjoy:

Joe Ferris Developer

Sharpen your programing skills by completing coding exercises that are reviewed by other developers at Upcase today.