Mock vs Real: The Art of Testing in Rails

Posted May 24, 2025

By Joey

12 min read

Alright, let’s be honest. Building software isn’t just about cranking out features; it’s about making sure the damn thing works. And that, my friends, brings us directly to testing. We all know we need it, but the constant tug-of-war between making tests lightning-fast and making them actually useful – that’s the real challenge.

We’re talking about the age-old dilemma: when do you mock the world, and when do you let your code chew on the real thing? There’s no silver bullet, but there’s a hell of a lot of strategy involved. The goal isn’t to pick a side; it’s to play both sides like a pro, getting speed where it counts and iron-clad confidence where it really counts.

Mocks: Your Best Friend Who Can Stab You in the Back

Look, we love mocks. Seriously, who doesn’t? When you’re dealing with external APIs, flaky third-party services, or slow-as-molasses databases, mocking is a godsend.

Zoom! Your Tests Are Fast: No waiting on network calls, no wrestling with external dependencies. Your tests fly, your CI pipeline sings, and you get feedback now.
“It Works On My Machine!” (Actually, It Does): Mocks make your tests deterministic. No more “flaky test” excuses because some external service had a hiccup. Your tests pass because your code’s logic is sound.
Focus, Focus, Focus: When you mock out the noise, you can laser-focus on the specific unit of code you’re testing. Is this function doing what it’s supposed to? Yes? Good, move on.

But here’s the kicker, the part nobody wants to talk about at the dev happy hour: too many mocks, or poorly managed mocks, can totally betray you.

The “Drift” Demon: External APIs change. Database schemas evolve. Your mocks, meanwhile, are sitting there, blissfully unaware, still mimicking a world that no longer exists. You push to production, and BAM! Integration failure. Your tests lied to you.
The Blind Spot: Mocks hide real-world complexity. You might perfectly mock a service, but if your code passes the wrong header, or misinterprets an edge-case error from the real service, your mock-laden tests won’t catch it.
False Sense of Security: The worst outcome. Your test suite is green, you feel like a rockstar, but deep down, you know it’s a house of cards. That gut feeling? It’s usually right.

The Balancing Act: Playing Chess, Not Checkers, With Your Tests

So, how do we get the best of both worlds? It’s about being smart, strategic, and understanding the role of different test types.

1. The OG: The Test Pyramid (It’s Still Relevant, Folks)

This isn’t some academic wankery; the test pyramid is a practical guide.

Unit Tests (The Big Base - ~70% of your tests): This is where you go mock-wild. Isolate everything. Your method, your class – that’s all you care about.

Rails Dev Translation: Think your model specs. Is user.authenticate_password working? Mock the BCrypt hashing if you want, but really, just test the method itself. If your Product model calls an InventoryService, mock that InventoryService into oblivion. RSpec’s allow(...).to receive(...) is your daily bread. double, instance_double, class_double? Use ‘em.

Code Glimpse (RSpec Model Spec with Mocking):

  
# app/models/product.rb
class Product < ApplicationRecord
  def available_stock
    # This is the external call we want to control
    InventoryService.current_stock(id)
  end
end

# spec/models/product_spec.rb
require 'rails_helper'

RSpec.describe Product, type: :model do
  describe '#available_stock' do
    let(:product) { create(:product, id: 123) }

    before do
      # We're telling RSpec: "When InventoryService.current_stock is called with this ID,
      # DON'T go to the real service. Just give me 50."
      allow(InventoryService).to receive(:current_stock).with(product.id).and_return(50)
    end

    it 'fetches and returns the available stock from the (mocked) inventory service' do
      expect(product.available_stock).to eq(50)
    end
  end
end

Integration Tests (The Middle Ground - ~20%): Now we’re talking about components talking to each other. Maybe your controller talks to a service, which talks to a database. This is where you start using real stuff, but with a safety net for external dependencies.

Rails Dev Translation: Request specs are prime candidates. Your API endpoint should hit your real database, but if it calls out to Stripe or a different microservice, that’s where VCR or WebMock comes in. You’re still mocking, but at the network layer, which is a much more realistic simulation.

Code Glimpse (RSpec Request Spec with VCR):

  
# config/initializers/vcr.rb (you set this up once)
VCR.configure do |config|
  config.cassette_library_dir = "spec/vcr_cassettes" # Where your recorded responses live
  config.hook_into :webmock # Integrates with WebMock
  config.allow_http_connections_when_no_cassette = false # Crucial! Fail if you hit real web without a cassette
end

# spec/requests/api/v1/products_spec.rb
require 'rails_helper'

RSpec.describe 'Products API', type: :request do
  describe 'GET /api/v1/products/:id' do
    let!(:product) { create(:product, id: 123, name: 'Super Widget') }

    # VCR will record the *actual* HTTP call to api.inventory.com the first time.
    # Subsequent runs will replay it, making the test fast and stable.
    it 'returns product details including stock from external service', vcr: { cassette_name: 'inventory_service/product_123_stock_success' } do
      get "/api/v1/products/#{product.id}"

      expect(response).to have_http_status(:ok)
      json_response = JSON.parse(response.body)
      expect(json_response['product']['name']).to eq('Super Widget')
      expect(json_response['stock']).to eq(50) # This '50' comes from the recorded cassette!
    end
  end
end

End-to-End (E2E) Tests (The Tiny Tip - ~10%): This is where you throw caution to the wind (almost). Simulate a real user. Click buttons, fill forms, submit data. These hit everything – your database, your frontend JS, and if your staging environment is configured right, even your real external services (or very realistic mock servers). They’re slow, they’re fragile, but they give you that warm, fuzzy feeling of “it actually works!”

Rails Dev Translation: Your system tests (powered by Capybara and a real browser like Headless Chrome). Don’t mock here if you can avoid it. You’re verifying the entire stack.

Code Glimpse (RSpec System Spec with Capybara):

  
# spec/system/product_Browse_spec.rb
require 'rails_helper'

RSpec.describe 'Product Browse', type: :system do
  before do
    driven_by(:selenium_chrome_headless) # Or whatever browser driver you use
    # No mocks here, or extremely high-level ones managed by the test environment itself.
    # We're relying on the actual application setup.
  end

  let!(:product) { create(:product, id: 123, name: 'Amazing Gizmo', description: 'Just buy it.') }

  it 'user can browse to a product page and see its details and real-time stock' do
    # This test implies the real InventoryService, or a very accurate mock service
    # running in your test environment, will respond correctly.
    visit product_path(product)

    expect(page).to have_text('Amazing Gizmo')
    expect(page).to have_text('Just buy it.')
    # This '75' should come from the *actual* (or very realistic test setup) external service
    expect(page).to have_text('Available Stock: 75')
  end
end

2. Test Suites: When to Run What

It’s not just what tests you write, but when you run them.

Suite Type	Mocked?	Purpose	Run Frequency
Unit Tests	Yeah, mostly	Instant feedback, CI/CD safety	Every commit/PR
Integration Tests	Some, with VCR	Component interaction, API contracts	Nightly / Staging builds
E2E Tests	Nope, full stack	Real-world confidence, user flows	Pre-release / Prod

3. Mocking Smarter: Don’t Just Make It Up

The biggest risk with mocks is they lie. So make them tell the truth, as much as possible.

VCR (Ruby Gem): This is gold. It literally records real HTTP interactions and replays them. Your tests get the actual response body, headers, everything, but without hitting the network. It’s like having a perfect memory for external services.
WebMock: More low-level, allows you to stub HTTP requests precisely. Great for specific error conditions or responses you can’t easily record.
MSW (Mock Service Worker): If you’ve got a JavaScript-heavy Rails frontend, look into this. It mocks API calls in the browser, giving your frontend devs a consistent API to work against, even if the backend isn’t ready or reliable.

4. The Reality Check: Validating Your Mocks

Your mocks are lying to you sometimes. It’s not if, it’s when. So build in checks.

Occasional “Real” Runs in CI: Every now and then, let your integration tests hit the actual external services. Yes, they’ll be slower, and they might fail because the external service is down, but that’s the point! It’s an early warning system for drift.

Code Glimpse (CI Configuration for Real Runs):

  
# .github/workflows/ci.yml (Excerpt for GitHub Actions)
# ...
jobs:
  test:
    # ...
    steps:
    # ... (setup code)

    - name: Run RSpec (Unit & VCR-enabled Integration)
      run: bundle exec rspec

    # This job runs on a schedule (e.g., daily) to hit real services.
    # Make sure your external services are stable enough for this!
    - name: Run Select Integration Tests against real services (Nightly Health Check)
      if: github.event_name == 'schedule' # Only run on schedule
      env:
        # Custom flag to tell our tests to allow real connections
        ALLOW_REAL_EXTERNAL_CALLS: 'true'
      run: |
        # Run specific specs that deal with external services,
        # ensuring they're not accidentally using VCR for this run.
        bundle exec rspec spec/requests/api/v1/products_spec.rb --tag ~vcr
        # Or run a specific Rake task for these checks
        # bundle exec rake integration:real_service_checks

And in your Rails spec_helper.rb (or similar):

  
# spec/rails_helper.rb (simplified)
require 'webmock/rspec'
require 'vcr'

RSpec.configure do |config|
  # ...
  if ENV['ALLOW_REAL_EXTERNAL_CALLS'] == 'true'
    WebMock.allow_net_connect! # Let it rip!
    VCR.configure do |vcr_config|
      vcr_config.allow_http_connections_when_no_cassette = true
    end
  else
    WebMock.disable_net_connect!(allow_localhost: true) # Default: No real external calls
  end
  # ...
end

5. Contract Testing: The Unsung Hero

If you’re in a microservices world, this is non-negotiable. Contract testing (like with Pact) ensures that your “mock” of an API producer (or your expectation of a consumer) matches what the other service actually provides/expects.

Pact (Ruby Gem): Absolute lifesaver for microservices. Your Rails app (as a consumer) writes a test that defines what it expects from, say, an Order Service. Pact then generates a JSON “contract” file. The Order Service (provider) then takes that contract and runs its own tests against it, ensuring it lives up to the expectations. No more “their API changed and broke us!” surprises.

Code Glimpse (Pact Consumer Spec for a Rails App):

  
# spec/service_consumers/pact_spec.rb
require 'pact_helper'
require 'order_client' # This is *your* Rails app's client for the Order Service

RSpec.describe OrderClient, pact: true do
  subject { OrderClient.new('http://localhost:1234') } # Pact starts a mock service on this port

  describe '#get_order' do
    before do
      # This describes the interaction: "When our client asks for order 1,
      # the Order Service should give us a 200 with this JSON body."
      order_service
        .given('an order with ID 1 exists')
        .upon_receiving('a request for order ID 1')
        .with(method: :get, path: '/orders/1', headers: {'Accept' => 'application/json'})
        .will_respond_with(
          status: 200,
          headers: { 'Content-Type' => 'application/json' },
          body: { id: 1, total: 10.00, items: [{ name: 'Laptop' }] }
        )
    end

    it 'successfully fetches and parses the order details from the (mocked) Order Service' do
      response = subject.get_order(1)
      expect(response).to eq({ 'id' => 1, 'total' => 10.00, 'items' => [{ 'name' => 'Laptop' }] })
    end
  end
end

6. Don’t Let Slow Tests Be Your Bottleneck

Real tests are slow. Embrace it, but manage it.

Timeouts are Your Friend: Don’t let a stuck external dependency or a slow database query hang your CI for an hour. Set timeouts for your tests, especially system tests. Capybara’s default_max_wait_time is your pal.
Retry Logic: If an external API is occasionally flaky, build retry logic into your application code, then ensure your integration tests cover that. Your tests shouldn’t fail just because a remote server sneezed once.

The Bottom Line for Rails Devs

Local & CI: Mock the hell out of external services for unit and most integration tests. VCR is your champion for realistic HTTP mocking. WebMock for precise stubbing.
Staging & Pre-Prod: This is where you bring in the big guns. Run your Capybara system tests. Integrate Pact contract testing into your deploy pipeline.
Balance, Always Balance: Don’t just write system tests because they feel “real.” They’re slow and fragile. Nail your unit tests, sprinkle in smart integration tests, and then use E2E for critical user journeys.
Validate Your Mocks: That daily/weekly CI job that hits real services? It’s cheap insurance.
Tool Up: RSpec, Minitest, WebMock, VCR, Capybara, Pact – these are the weapons in your Rails testing arsenal. Learn ‘em, love ‘em.

At the end of the day, testing isn’t about hitting a percentage target or following dogma. It’s about building confidence. Confidence that your code does what it’s supposed to do, and confidence that it won’t blow up in production. By smartly balancing mocks and real calls, you’re not just writing tests; you’re building a fortress of reliability around your application. Now go forth and test!

testing, rails, software development

This post is licensed under CC BY 4.0 by the author.