Mocks: Why I've Stopped Using Them in My Tests
Mocks: Why I've Stopped Using Them in My Tests
January 10, 2025
Over the years, I’ve developed a strong distaste for mocks in testing. This isn’t just a matter of personal preference – it stems from witnessing their widespread misuse and the subsequent problems they introduce into codebases. Let me explain why I’ve chosen to move away from mocks and what I’ve learned in the process.
Misuse of mocks
The Mock Inception Problem
One of the most troubling patterns I’ve encountered is the phenomenon of “mocks returning mocks.”, making it increasingly difficult to understand what’s actually being tested.
// An example of mock inception - this is what we want to avoid
describe('UserService', () => {
it('should process user data', () => {
const mockDatabase = jest.mock('Database');
// Mock returns another mock
mockDatabase.getUser.mockReturnValue({
getProfile: jest.fn().mockReturnValue({
getPreferences: jest.fn().mockReturnValue({
theme: 'dark'
})
})
});
const service = new UserService(mockDatabase);
const result = service.getUserPreferences(1);
expect(result.theme).toBe('dark');
// What are we actually testing here?
});
});Hidden Behaviors and Incomplete Verification
Mocks make it too easy to sweep complex behaviors under the rug. Here’s an example of incomplete verification:
// Bad: Important behavior is hidden behind mocks
describe('PaymentProcessor', () => {
it('should process payment', async () => {
const mockStripe = jest.mock('stripe');
mockStripe.charges.create.mockResolvedValue({id: 'ch_123'});
const processor = new PaymentProcessor(mockStripe);
await processor.processPayment(100, 'usd');
// Only verifying the call was made, not the actual behavior
expect(mockStripe.charges.create).toHaveBeenCalled();
});
});
// Better: Using an in-memory implementation with explicit behavior
interface PaymentGateway {
createCharge(amount: number, currency: string): Promise<PaymentResult>;
}
class InMemoryPaymentGateway implements PaymentGateway {
private charges: PaymentResult[] = [];
async createCharge(amount: number, currency: string): Promise<PaymentResult> {
if (amount <= 0) throw new Error('Invalid amount');
const charge = {id: `inmemory_${Date.now()}`, amount, currency};
this.charges.push(charge);
return charge;
}
getCharges(): PaymentResult[] {
return this.charges;
}
}The Import Override Trap
Modern mocking frameworks offer powerful features like import overriding, but this power comes at a significant cost. Specifically it hides dependencies on other objects and external systems.
// Bad: Mocking imports directly
jest.mock('fs');
import {readFile} from 'fs';
// Who knew the ConfigLoader used 'fs' under the hood??
describe('ConfigLoader', () => {
it('should load config', async () => {
(readFile as jest.Mock).mockResolvedValue('{"key": "value"}');
const config = await ConfigLoader.load();
expect(config.key).toBe('value');
});
});
// Better: Explicit dependency injection
interface FileSystem {
readFile(path: string): Promise<string>;
}
class ConfigLoader {
constructor(private fs: FileSystem) {
}
async load(): Promise<Config> {
const content = await this.fs.readFile('config.json');
return JSON.parse(content);
}
}
// In-memory implementation
class InMemoryFileSystem implements FileSystem {
private files: Map<string, string> = new Map();
async readFile(path: string): Promise<string> {
const content = this.files.get(path);
if (!content) throw new Error('File not found');
return content;
}
setFile(path: string, content: string): void {
this.files.set(path, content);
}
}The Third-Party Dependency Problem
Instead of mocking third-party code directly, create proper abstractions:
// Bad: Direct mocking of third-party code
describe('EmailService', () => {
it('should send email', async () => {
const mockSendGrid = jest.mock('@sendgrid/mail');
const emailService = new EmailService();
await emailService.sendWelcomeEmail('user@example.com');
expect(mockSendGrid.send).toHaveBeenCalled();
});
});
// Better: Abstract third-party dependencies
interface EmailProvider {
sendEmail(to: string, subject: string, content: string): Promise<void>;
}
class SendGridEmailProvider implements EmailProvider {
constructor(private client: any) {
} // SendGrid client
async sendEmail(to: string, subject: string, content: string): Promise<void> {
await this.client.send({
to,
subject,
content,
from: 'noreply@example.com'
});
}
}
// In-memory implementation
class InMemoryEmailProvider implements EmailProvider {
private sentEmails: Array<{ to: string, subject: string, content: string }> = [];
async sendEmail(to: string, subject: string, content: string): Promise<void> {
this.sentEmails.push({to, subject, content});
}
getSentEmails() {
return this.sentEmails;
}
}The Benefits of Abandoning Mocks
Explicit Dependencies
When dependencies are explicit, the code becomes more transparent:
// Clear dependencies in the constructor
class OrderProcessor {
constructor(
private inventory: InventoryService,
private payments: PaymentService,
private notifications: NotificationService
) {
}
async processOrder(order: Order): Promise<OrderResult> {
// Implementation
}
}
// Easy to test with in-memory implementations
describe('OrderProcessor', () => {
it('should process valid order', async () => {
const inventory = new InMemoryInventoryService();
const payments = new InMemoryPaymentService();
const notifications = new InMemoryNotificationService();
const processor = new OrderProcessor(
inventory,
payments,
notifications
);
await processor.processOrder(testOrder);
// Verify behavior using real objects
expect(inventory.getReservedItems()).toContain(testOrder.itemId);
expect(payments.getProcessedPayments()).toHaveLength(1);
expect(notifications.getSentNotifications()).toHaveLength(1);
});
});Better Abstractions
Create meaningful interfaces that represent real behavior:
interface Cache {
get(key: string): Promise<string | null>;
set(key: string, value: string, ttlSeconds?: number): Promise<void>;
delete(key: string): Promise<void>;
}
// Real Redis implementation
class RedisCache implements Cache {
constructor(private client: Redis) {
}
async get(key: string): Promise<string | null> {
return this.client.get(key);
}
async set(key: string, value: string, ttlSeconds?: number): Promise<void> {
if (ttlSeconds) {
await this.client.setex(key, ttlSeconds, value);
} else {
await this.client.set(key, value);
}
}
async delete(key: string): Promise<void> {
await this.client.del(key);
}
}
// In-memory implementation
class InMemoryCache implements Cache {
private store = new Map<string, { value: string; expiresAt?: number }>();
async get(key: string): Promise<string | null> {
const item = this.store.get(key);
if (!item) return null;
if (item.expiresAt && item.expiresAt < Date.now()) {
this.store.delete(key);
return null;
}
return item.value;
}
async set(key: string, value: string, ttlSeconds?: number): Promise<void> {
this.store.set(key, {
value,
expiresAt: ttlSeconds ? Date.now() + ttlSeconds * 1000 : undefined
});
}
async delete(key: string): Promise<void> {
this.store.delete(key);
}
}Controlled Interfaces
Design interfaces that are both testable and meaningful:
interface MessageQueue {
publish(topic: string, message: any): Promise<void>;
subscribe(topic: string, handler: (message: any) => Promise<void>): Promise<void>;
}
// Production implementation using RabbitMQ
class RabbitMQQueue implements MessageQueue {
constructor(private connection: amqp.Connection) {
}
async publish(topic: string, message: any): Promise<void> {
const channel = await this.connection.createChannel();
await channel.assertExchange(topic, 'fanout');
await channel.publish(topic, '', Buffer.from(JSON.stringify(message)));
}
async subscribe(
topic: string,
handler: (message: any) => Promise<void>
): Promise<void> {
const channel = await this.connection.createChannel();
await channel.assertExchange(topic, 'fanout');
const queue = await channel.assertQueue('', {exclusive: true});
await channel.bindQueue(queue.queue, topic, '');
await channel.consume(queue.queue, async (msg) => {
if (msg) {
await handler(JSON.parse(msg.content.toString()));
channel.ack(msg);
}
});
}
}
// In-memory implementation
class InMemoryMessageQueue implements MessageQueue {
private handlers = new Map<string, Array<(message: any) => Promise<void>>>();
private messages: Array<{ topic: string; message: any }> = [];
async publish(topic: string, message: any): Promise<void> {
this.messages.push({topic, message});
const topicHandlers = this.handlers.get(topic) || [];
await Promise.all(topicHandlers.map(handler => handler(message)));
}
async subscribe(
topic: string,
handler: (message: any) => Promise<void>
): Promise<void> {
const handlers = this.handlers.get(topic) || [];
handlers.push(handler);
this.handlers.set(topic, handlers);
}
getPublishedMessages(): Array<{ topic: string; message: any }> {
return this.messages;
}
}Conclusion
While mocks have their place in certain specific scenarios, I’ve found that generally avoiding them in favor of in-memory implementations leads to better system design and more maintainable code. Yes, it’s more challenging initially, but the benefits of clearer dependencies, better abstractions, and more reliable tests make it worth the effort.
Remember: just because your mocking framework makes something possible doesn’t mean it’s the right thing to do. Sometimes, avoiding ‘cleverness’ and keeping it simple makes for a better design.