Understanding Mocking and Stubbing in Ruby Tests

When you’re writing tests in Ruby, grasping the concepts of mocking and stubbing is absolutely key. These techniques help isolate different parts of your code, making your tests more reliable and easier to maintain. Let’s dive into what mocking and stubbing are all about and how you can use them effectively in your Ruby tests. Ready to become a testing pro?

What Are Mocks and Stubs?

Imagine you’re making a movie. In the world of testing, mocks and stubs are like the stand-ins for your main actors. They take the place of real objects to make life a lot easier. The primary difference is in their roles:

1. Mocks: Mocks are all about verification. Imagine you’re the director, and you need to ensure that your actors deliver their lines perfectly in a certain scene. Mocks help confirm that specific methods are called with the right arguments.

2. Stubs: Stubs, on the other hand, are more about control. Think of them as actors who will say exactly what you want them to say in any given situation. They let you dictate how an object behaves, like deciding what a method should return, without actually calling the method.

Using Mocks

Mocks are your go-to when you need to verify interactions between objects. Suppose you’re working on a payment processing system and you want to check if a notification is sent correctly. Here’s how you might use a mock in an RSpec test:

describe PaymentProcessor do
  it "sends a payment notification" do
    notifier = double("notifier")
    expect(notifier).to receive(:notify).with("Payment successful")
    PaymentProcessor.new(notifier).process_payment
  end
end

In this case, notifier is the mock object standing in for the actual notification service. The test is all about verifying that the notify method is called with the right message. Super easy to understand, right?

Using Stubs

Stubs come in handy when you want to control how a dependent object behaves without really calling its methods. Picture this: You’re working on a User model and need to return a specific name no matter what. Here’s how you might handle that:

describe User do
  it "returns the user's name" do
    user = User.new(name: "John Doe")
    allow(user).to receive(:name).and_return("Jane Doe")
    expect(user.name).to eq("Jane Doe")
  end
end

In this snippet, the name method of the User object is stubbed to return “Jane Doe”, even though the actual name is “John Doe”. Pretty neat, huh?

Combining Mocks and Stubs

Sometimes, a situation calls for a mix of both mocks and stubs. Imagine you’re processing an order and need to send a confirmation email. Here’s what that might look like:

describe OrderProcessor do
  it "processes an order and sends a confirmation email" do
    order = Order.new
    mailer = double("mailer")
    expect(mailer).to receive(:send_email).with(order)
    allow(OrderMailer).to receive(:new).and_return(mailer)
    OrderProcessor.new.process_order(order)
  end
end

In this example, the mailer mock verifies that the email sending method is called, while the OrderMailer class is stubbed to return this mock mailer. This keeps the test focused on the behavior of the OrderProcessor class.

Advanced Techniques

Delegating to the Original Implementation

Sometimes, you might want to set an expectation without changing how the object responds to a message. Use and_call_original to make this happen:

expect(Person).to receive(:find).and_call_original
Person.find # => executes the original find method and returns the result

This is super useful when you want to test the interaction but still allow the original method to be called.

Arbitrary Handling

You might run into cases where the available expectations don’t quite fit your needs. For instance, you might want to verify a method is called with an array of a specific length, without caring about the contents:

expect(double).to receive(:msg) do |arg|
  expect(arg.size).to eq 7
end

This approach gives you the flexibility to handle complex expectations with ease.

Stubbing and Hiding Constants

When dealing with constants, stubbing them can be tricky because they aren’t instance methods. Special techniques are required to change constants, but this is generally discouraged due to potential complexity and side effects.

Best Practices

Use Before Example

When setting up stubs or mocks, it’s crucial to use before(:example) instead of before(:context). This ensures that all stubs and mocks are cleared out after each example, allowing each test to run independently and without interference.

Avoid Overuse of Mocks and Stubs

Mocks and stubs can be super powerful, but it’s easy to overdo it. Overusing them can make your tests fragile and too dependent on the internal details of your code. Sometimes, it’s better to test the outcome of an action rather than its implementation.

Dependency Injection

Dependency injection is a pattern that makes your code easier to test by allowing you to replace dependencies with mocks or stubs effortlessly. Here’s an example using a UserGreeter class:

class UserGreeter
  def initialize(name:, notifier: Slack)
    @name = name
    @notifier = notifier # store replaceable collaborator object
  end

  def run
    msg = whatever(@name)
    @notifier.notify(msg) # use injected dependency by internal name
  end
end

# In the test
require 'test_helper'

class UserGreeterTest < ActiveSupport::TestCase
  test '#run' do
    mock = Minitest::Mock.new
    mock.expect :notify, true, [String]
    user = User.new(user_attrs.merge(subscription_service: mock))
    assert user.run
    assert_mock mock
  end
end

This pattern simplifies testing and refactoring by decoupling dependencies.

Conclusion

Mocking and stubbing are indispensable for writing robust Ruby tests. By mastering mocks to verify interactions and stubs to control behavior, your tests become more reliable and maintainable. Just be mindful not to overuse these tools, and follow best practices to keep your tests from becoming overly complex. With these techniques in your toolbox, you’ll be well-equipped to write efficient, effective tests for your Ruby applications. So go ahead, dive into your Ruby code, and make those tests rock-solid!