Unit Tests vs Integration Tests

Direct Answer

A unit test checks one small unit of behaviour with most external boundaries controlled; an integration test checks that multiple real parts work together. In Rails, a focused test of a pricing object is unit-like, while an ActionDispatch::IntegrationTest or RSpec request spec can exercise routing, controller behaviour, rendering, and persistence together. Unit tests are fast and precise; integration tests give broader confidence. A healthy suite uses both according to the risk being tested.

Deep Dive & Architecture

Test scope describes how much real collaboration occurs. A calculation with plain values has a narrow boundary. Adding Active Record, the database, a job adapter, or an HTTP client widens it. The useful distinction is not whether the production subject is a class, but which dependencies the test lets participate.

A controlled dependency can make a focused test deterministic. A fake exchange-rate client lets pricing tests cover timeout or invalid-rate behaviour without a network. That test must still respect the real client's local contract, and a separate integration or contract test should confirm the adapter speaks to its actual boundary correctly.

Broad tests are best spent on paths whose connections matter: authentication plus authorization, parameter parsing plus validation errors, a successful transaction, or an external adapter's serialization. Repeating every small rule at that level creates slow setup without adding a new relationship to verify.

When a test fails, its scope determines the search area. Narrow tests give precise feedback; broad tests show the product path is broken. Keeping both layers allows a broad failure to reveal impact and a focused failure to reveal the responsible rule.

Code Example

# Focused unit-like test
RSpec.describe ShippingFee do
  it 'waives shipping at the free-delivery threshold' do
    expect(described_class.for(order_total: 50)).to eq(0)
  end
end

# Integration boundary
RSpec.describe 'Checkout', type: :request do
  it 'returns the calculated delivery charge' do
    post '/checkout', params: { order_total: 40 }, as: :json
    expect(response).to have_http_status(:ok)
    expect(response.parsed_body['shipping_fee']).to eq(5)
  end
end

Common Mistakes & Pitfalls

Only integration tests (slow, hard to localize) or only unit (misses wiring bugs) — balance the pyramid.