Test Mocking

Test Mocking

Mock external dependencies to create fast, isolated, and deterministic tests. This skill covers mocking strategies applicable across testing frameworks and programming languages.

When to Use This Skill

• User asks to "mock dependencies", "create mocks", "use test doubles"
• Testing code with external dependencies (databases, APIs, cloud services)
• Creating unit tests that run without credentials
• Avoiding slow or expensive resource creation in tests
• Isolating code under test from infrastructure dependencies
• Making tests deterministic and reproducible
• Testing error handling without triggering real errors

Types of Test Doubles

1. Mock

Definition: Object that verifies behavior (interactions)

Use when: You need to verify a method was called with specific arguments

Example (JavaScript/Jest):

const emailService = {
  send: jest.fn()
};

sendWelcomeEmail(user, emailService);

expect(emailService.send).toHaveBeenCalledWith({
  to: user.email,
  subject: 'Welcome!'
});

Example (Python/unittest.mock):

from unittest.mock import Mock

email_service = Mock()
send_welcome_email(user, email_service)

email_service.send.assert_called_once_with(
    to=user.email,
    subject='Welcome!'
)

2. Stub

Definition: Object that provides canned responses

Use when: You need to control return values

Example (JavaScript):

const database = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: 'John' })
};

const user = await fetchUserProfile(1, database);
expect(user.name).toBe('John');

Example (Python):

database = Mock()
database.get_user.return_value = {'id': 1, 'name': 'John'}

user = fetch_user_profile(1, database)
assert user['name'] == 'John'

3. Fake

Definition: Working implementation with shortcuts

Use when: You need realistic behavior without full complexity

Example (In-Memory Database):

class FakeUserRepository {
  constructor() {
    this.users = new Map();
  }

  save(user) {
    this.users.set(user.id, user);
    return Promise.resolve(user);
  }

  findById(id) {
    return Promise.resolve(this.users.get(id));
  }
}

// Use in tests
const repo = new FakeUserRepository();
await repo.save({ id: 1, name: 'John' });
const user = await repo.findById(1);

Example (Python):

class FakeUserRepository:
    def __init__(self):
        self.users = {}

    def save(self, user):
        self.users[user.id] = user
        return user

    def find_by_id(self, user_id):
        return self.users.get(user_id)

4. Spy

Definition: Records information about calls while delegating to real object

Use when: You want real behavior + verification

Example (JavaScript):

const realService = {
  processPayment: (amount) => ({ success: true, amount })
};

const spy = jest.spyOn(realService, 'processPayment');

const result = realService.processPayment(100);

expect(result.success).toBe(true);
expect(spy).toHaveBeenCalledWith(100);

Mocking Strategies

Strategy 1: Dependency Injection

Principle: Pass dependencies as parameters instead of creating them internally

❌ Hard to test (dependencies hardcoded):

function sendWelcomeEmail(user) {
  const emailService = new EmailService(); // Hard-coded dependency
  emailService.send({
    to: user.email,
    subject: 'Welcome!'
  });
}

✅ Easy to test (dependency injected):

function sendWelcomeEmail(user, emailService) {
  emailService.send({
    to: user.email,
    subject: 'Welcome!'
  });
}

// In test
const mockEmailService = { send: jest.fn() };
sendWelcomeEmail(user, mockEmailService);

Strategy 2: Interface-Based Mocking

Principle: Depend on interfaces/protocols, not concrete implementations

Example (TypeScript):

interface EmailService {
  send(message: EmailMessage): Promise<void>;
}

class RealEmailService implements EmailService {
  async send(message: EmailMessage) {
    // Real SMTP implementation
  }
}

class MockEmailService implements EmailService {
  async send(message: EmailMessage) {
    // Mock implementation for testing
  }
}

Strategy 3: Environment-Based Mocking

Principle: Use environment detection to swap implementations

Example (Terraform - Mock Provider):

mock_provider "aws" {}

run "test_without_credentials" {
  # Provider mocked - no AWS calls
}

Example (JavaScript - Environment Check):

const emailService = process.env.NODE_ENV === 'test'
  ? new MockEmailService()
  : new RealEmailService();

Strategy 4: Module/Import Mocking

Principle: Replace entire modules during test execution

Example (Jest):

// In test file
jest.mock('./emailService', () => ({
  sendEmail: jest.fn()
}));

const { sendEmail } = require('./emailService');

// sendEmail is now a mock function

Example (Python unittest.mock):

from unittest.mock import patch

@patch('myapp.email_service.send_email')
def test_send_welcome_email(mock_send):
    send_welcome_email(user)
    mock_send.assert_called_once()

When to Mock vs When to Use Real Implementation

✅ Mock When:

1. Dependency is slow

   • Database queries
   • Network requests
   • File system operations
   • Cloud provider API calls

2. Dependency is non-deterministic

   • Random number generators
   • Current time/date
   • External API responses

3. Dependency is expensive

   • Cloud resource creation (EC2, S3, etc.)
   • Payment processing
   • SMS/email sending

4. Dependency is unavailable

   • No test credentials
   • Service not in test environment
   • Rate-limited APIs

5. Testing error conditions

   • Network timeouts
   • Service failures
   • Invalid responses

❌ Don't Mock When:

1. Testing integration points

   • Verifying actual service behavior
   • End-to-end tests
   • Contract testing

2. Dependency is simple and fast

   • Pure functions
   • Simple calculations
   • In-memory operations

3. Mock would be as complex as real implementation

   • Over-mocking leads to brittle tests
   • Test the real behavior instead

4. You're testing the thing you'd mock

   • Don't mock the system under test
   • Only mock dependencies

Framework-Specific Examples

Terraform Mock Provider

Basic Mock:

mock_provider "aws" {}

run "unit_test" {
  command = plan

  assert {
    condition     = aws_s3_bucket.bucket.bucket == "expected-name"
    error_message = "Naming logic incorrect"
  }
}

Mock with Defaults:

mock_provider "aws" {
  mock_resource "aws_s3_bucket" {
    defaults = {
      arn = "arn:aws:s3:::test-bucket"
    }
  }
}

Override Specific Resources:

override_resource {
  target = aws_rds_instance.database
  values = {
    endpoint = "mock-db.us-east-1.rds.amazonaws.com:5432"
  }
}

run "test_without_rds" {
  # RDS not created, uses override values
}

JavaScript/Jest Mocking

Mock Function:

const mockFn = jest.fn();
mockFn.mockReturnValue(42);

expect(mockFn()).toBe(42);
expect(mockFn).toHaveBeenCalled();

Mock Module:

jest.mock('./api', () => ({
  fetchUser: jest.fn().mockResolvedValue({ id: 1, name: 'John' })
}));

Spy on Method:

const spy = jest.spyOn(object, 'method');
spy.mockImplementation(() => 'mocked value');

expect(object.method()).toBe('mocked value');
expect(spy).toHaveBeenCalled();

Python Mock (unittest.mock)

Mock Object:

from unittest.mock import Mock

mock_db = Mock()
mock_db.get_user.return_value = {'id': 1, 'name': 'John'}

user = service.fetch_user(1, mock_db)
mock_db.get_user.assert_called_once_with(1)

Patch Decorator:

from unittest.mock import patch

@patch('myapp.database.connection')
def test_fetch_user(mock_connection):
    mock_connection.query.return_value = [{'id': 1}]
    result = fetch_user(1)
    assert result['id'] == 1

Context Manager:

from unittest.mock import patch

def test_send_email():
    with patch('myapp.email.send') as mock_send:
        send_welcome_email(user)
        mock_send.assert_called_once()

Go Mocking (Interfaces)

Define Interface:

type UserRepository interface {
    GetUser(id int) (*User, error)
    SaveUser(user *User) error
}

Mock Implementation:

type MockUserRepository struct {
    GetUserFunc func(id int) (*User, error)
    SaveUserFunc func(user *User) error
}

func (m *MockUserRepository) GetUser(id int) (*User, error) {
    return m.GetUserFunc(id)
}

func (m *MockUserRepository) SaveUser(user *User) error {
    return m.SaveUserFunc(user)
}

Use in Test:

func TestFetchUserProfile(t *testing.T) {
    mockRepo := &MockUserRepository{
        GetUserFunc: func(id int) (*User, error) {
            return &User{ID: 1, Name: "John"}, nil
        },
    }

    user, err := FetchUserProfile(1, mockRepo)
    assert.NoError(t, err)
    assert.Equal(t, "John", user.Name)
}

Mock Data Management

Shared Mock Data Files

Terraform:

# tests/mocks/aws.tfmock.hcl
mock_resource "aws_s3_bucket" {
  defaults = {
    arn = "arn:aws:s3:::test-bucket"
  }
}

mock_data "aws_ami" {
  defaults = {
    id = "ami-12345678"
  }
}

# tests/unit.tftest.hcl
mock_provider "aws" {
  source = "./tests/mocks"
}

JavaScript:

// tests/fixtures/users.js
export const mockUsers = [
  { id: 1, name: 'John', email: 'john@example.com' },
  { id: 2, name: 'Jane', email: 'jane@example.com' }
];

// In test
import { mockUsers } from './fixtures/users';
database.getUsers.mockResolvedValue(mockUsers);

Python:

# tests/fixtures/users.py
MOCK_USERS = [
    {'id': 1, 'name': 'John', 'email': 'john@example.com'},
    {'id': 2, 'name': 'Jane', 'email': 'jane@example.com'}
]

# In test
from tests.fixtures.users import MOCK_USERS
mock_db.get_users.return_value = MOCK_USERS

Best Practices

1. Mock at the Boundaries

✅ Good - Mock external services:

// Mock HTTP client
const mockHttp = {
  get: jest.fn().mockResolvedValue({ data: { user: 'John' } })
};

// Test your service
const result = await userService.fetchUser(1, mockHttp);

❌ Bad - Mock internal logic:

// Don't mock the thing you're testing
jest.mock('./userService');
const userService = require('./userService');
userService.fetchUser.mockResolvedValue({ user: 'John' });

2. Verify Behavior, Not Implementation

✅ Good - Test outcomes:

await sendWelcomeEmail(user, emailService);

expect(emailService.send).toHaveBeenCalledWith(
  expect.objectContaining({
    to: user.email,
    subject: expect.stringContaining('Welcome')
  })
);

❌ Bad - Test implementation details:

// Too brittle - breaks when implementation changes
expect(emailService.send).toHaveBeenCalledTimes(1);
expect(emailService.send.mock.calls[0][0].to).toBe(user.email);

3. Keep Mocks Simple

✅ Good - Simple, focused mock:

const mockDatabase = {
  getUser: jest.fn().mockResolvedValue({ id: 1, name: 'John' })
};

❌ Bad - Complex mock duplicating real implementation:

const mockDatabase = {
  getUser: jest.fn(async (id) => {
    // Don't reimplement the real database logic
    const users = await loadFromFile();
    return users.find(u => u.id === id);
  })
};

4. Reset Mocks Between Tests

JavaScript:

beforeEach(() => {
  jest.clearAllMocks();
});

Python:

def setup_method(self):
    self.mock_db = Mock()

5. Use Realistic Test Data

✅ Good - Realistic data:

const mockUser = {
  id: 'usr_1234567890',
  email: 'john.doe@example.com',
  created_at: '2024-01-15T10:30:00Z'
};

❌ Bad - Unrealistic data:

const mockUser = {
  id: 1,
  email: 'test',
  created_at: 'now'
};

Anti-Patterns

❌ Over-Mocking

Problem: Mocking everything, including simple logic

// Don't do this
jest.mock('./utils/add');
const add = require('./utils/add');
add.mockReturnValue(5);

expect(add(2, 3)).toBe(5);
// You're testing the mock, not the code!

Solution: Only mock external dependencies

❌ Leaky Mocks

Problem: Mock state persists between tests

describe('User tests', () => {
  const mockDb = { getUser: jest.fn() };

  test('test 1', () => {
    mockDb.getUser.mockResolvedValue({ id: 1 });
  });

  test('test 2', () => {
    // Mock still has state from test 1!
  });
});

Solution: Reset mocks in beforeEach

❌ Mocking the System Under Test

Problem: Mocking the code you're trying to test

// Don't do this
jest.mock('./orderService');
const orderService = require('./orderService');
orderService.createOrder.mockResolvedValue({ id: 1 });

// You're not testing anything!
const result = await orderService.createOrder();

Solution: Only mock dependencies, test real implementation

Mocking Decision Tree

Ask yourself:

1. Is it an external dependency?

   • ✅ Yes → Consider mocking
   • ❌ No → Don't mock

2. Is it slow or expensive?

   • ✅ Yes → Mock for unit tests
   • ❌ No → Use real implementation

3. Is it the code under test?

   • ✅ Yes → Never mock
   • ❌ No → Can mock

4. Does mocking simplify the test?

   • ✅ Yes → Mock
   • ❌ No → Keep it real

5. Am I testing integration?

   • ✅ Yes → Don't mock
   • ❌ No → Can mock

References

• Test Doubles: https://martinfowler.com/bliki/TestDouble.html
• Mocking Best Practices: https://kentcdodds.com/blog/mocking-is-a-code-smell
• Terraform Mocking: https://developer.hashicorp.com/terraform/language/tests/mocking
• Jest Mocking: https://jestjs.io/docs/mock-functions
• Python unittest.mock: https://docs.python.org/3/library/unittest.mock.html
• Test Assertions: Use the test-assertions skill for validation patterns
• Test Organization: Use the test-organization-patterns skill for test structure

Converted and distributed by TomeVault — claim your Tome and manage your conversions.