Simulation and stubbing

Concepts of Mock and Stub

Mock and Stub are two commonly used techniques in testing. Both can isolate dependencies of the code under test, but they focus on different aspects. Mocks emphasize behavior verification, while Stubs focus on state control. In Node.js, these two techniques are often combined to build reliable test suites.

Mock objects record call information and verify whether these calls meet expectations after the test completes. For example, checking if a function was called, the number of calls, and whether the parameters were correct. Stubs are predefined fixed return values used to replace the behavior of real dependencies.

// Mock example
const mockFn = jest.fn();
mockFn('hello');
expect(mockFn).toHaveBeenCalledWith('hello');

// Stub example
const stub = jest.fn().mockReturnValue(42);
expect(stub()).toBe(42);

Support in Node.js Testing Frameworks

Jest and Sinon are the most commonly used testing tools in the Node.js ecosystem. Jest has built-in rich mocking capabilities, while Sinon provides more granular control. Mocha typically needs to be used in combination with Sinon.

Jest's auto-mocking feature can easily create mock versions of modules:

// userService.js
export default {
  getUser: async (id) => {
    // Actual implementation
  }
};

// test.js
jest.mock('./userService');
import userService from './userService';

test('should mock module', async () => {
  userService.getUser.mockResolvedValue({id: 1, name: 'Mock User'});
  const user = await userService.getUser(1);
  expect(user.name).toBe('Mock User');
});

Sinon provides three types of test doubles: spies (monitor function calls), stubs (replace function implementations), and mocks (combined functionality):

const sinon = require('sinon');
const fs = require('fs');

const readStub = sinon.stub(fs, 'readFile');
readStub.withArgs('/path/to/file').yields(null, 'file content');

fs.readFile('/path/to/file', (err, data) => {
  console.log(data); // Output: file content
});

readStub.restore();

Mocking HTTP Requests

When testing code involving HTTP requests, the nock library can intercept and mock HTTP requests:

const nock = require('nock');
const axios = require('axios');

nock('https://api.example.com')
  .get('/users/1')
  .reply(200, { id: 1, name: 'John Doe' });

test('should mock HTTP request', async () => {
  const response = await axios.get('https://api.example.com/users/1');
  expect(response.data.name).toBe('John Doe');
});

For more complex scenarios, error responses can be mocked:

nock('https://api.example.com')
  .post('/users')
  .reply(500, { error: 'Internal Server Error' });

test('should handle HTTP errors', async () => {
  await expect(axios.post('https://api.example.com/users'))
    .rejects.toThrow('Request failed with status code 500');
});

Mocking Database Operations

When testing database-related code, it is usually undesirable to connect to a real database. In-memory databases or specialized mocking libraries can be used:

// Using Jest to mock Mongoose models
const mongoose = require('mongoose');
const User = mongoose.model('User');

jest.mock('../models/User');

test('should mock Mongoose model', async () => {
  User.findOne.mockResolvedValue({ _id: '123', name: 'Mock User' });
  
  const user = await User.findOne({ _id: '123' });
  expect(user.name).toBe('Mock User');
});

For Sequelize, sequelize-mock can be used:

const SequelizeMock = require('sequelize-mock');
const dbMock = new SequelizeMock();

const UserMock = dbMock.define('User', {
  name: 'John Doe',
  email: 'john@example.com'
});

test('should mock Sequelize model', async () => {
  const user = await UserMock.findOne();
  expect(user.name).toBe('John Doe');
});

Mocking Event Systems

Node.js's event system (EventEmitter) also needs to be mocked in tests:

const EventEmitter = require('events');
const emitter = new EventEmitter();

jest.spyOn(emitter, 'emit');

test('should verify event emission', () => {
  emitter.emit('data', { value: 42 });
  expect(emitter.emit).toHaveBeenCalledWith('data', { value: 42 });
});

For more complex event stream testing, specialized mock implementations can be created:

class MockStream extends EventEmitter {
  write(data) {
    this.emit('data', data);
    return true;
  }
}

test('should test stream handling', () => {
  const stream = new MockStream();
  const callback = jest.fn();
  
  stream.on('data', callback);
  stream.write('test data');
  
  expect(callback).toHaveBeenCalledWith('test data');
});

Mocking Timers

When testing code involving timers, Jest provides specialized timer mocking functionality:

jest.useFakeTimers();

test('should test setTimeout', () => {
  const callback = jest.fn();
  
  setTimeout(callback, 1000);
  jest.advanceTimersByTime(1000);
  
  expect(callback).toHaveBeenCalled();
});

For more complex timing scenarios:

test('should test intervals', () => {
  const callback = jest.fn();
  
  setInterval(callback, 1000);
  jest.advanceTimersByTime(5000);
  
  expect(callback).toHaveBeenCalledTimes(5);
});

Mocking the File System

Node.js's fs module can be fully mocked using jest.mock:

jest.mock('fs');

const fs = require('fs');

test('should mock fs.readFile', () => {
  fs.readFile.mockImplementation((path, encoding, callback) => {
    callback(null, 'mock file content');
  });
  
  fs.readFile('/path/to/file', 'utf8', (err, data) => {
    expect(data).toBe('mock file content');
  });
});

For finer control, memfs can be used to create an in-memory file system:

const { vol } = require('memfs');

beforeEach(() => {
  vol.reset();
  vol.mkdirpSync('/path/to');
  vol.writeFileSync('/path/to/file', 'content');
});

test('should use memory fs', () => {
  const content = vol.readFileSync('/path/to/file', 'utf8');
  expect(content).toBe('content');
});

Best Practices for Mocks and Stubs

1. Maintain Test Isolation: Each test should set up its own mocks and stubs to avoid interference between tests.
2. Avoid Over-Mocking: Only mock necessary dependencies, retaining as much real implementation as possible.
3. Prefer Real Implementations: When dependencies are simple enough and do not introduce uncertainty, use real implementations.
4. Clear Naming: Add Mock/Stub suffixes to variables for better readability.

// Bad practice
const user = jest.fn();

// Good practice
const userMock = jest.fn();
const dbStub = sinon.stub(db, 'query');

5. Clean Up Promptly: Restore original implementations after tests to avoid affecting other tests.

afterEach(() => {
  jest.clearAllMocks();
  sinon.restore();
});

Advanced Mocking Techniques

For mocks requiring complex behavior, multiple functionalities can be combined:

const complexMock = jest.fn()
  .mockImplementationOnce(() => 'first call')
  .mockImplementationOnce(() => { throw new Error('second call') })
  .mockImplementation(() => 'subsequent calls');

test('should use complex mock', () => {
  expect(complexMock()).toBe('first call');
  expect(() => complexMock()).toThrow('second call');
  expect(complexMock()).toBe('subsequent calls');
  expect(complexMock()).toBe('subsequent calls');
});

Mocking part of a module while retaining other real implementations:

jest.mock('some-module', () => {
  const originalModule = jest.requireActual('some-module');
  
  return {
    ...originalModule,
    unstableFunction: jest.fn()
  };
});

Patterns for Testing Asynchronous Code

When mocking asynchronous operations, various scenarios need to be considered:

// Mock successful response
apiMock.getUsers.mockResolvedValue([{id: 1}]);

// Mock error response
apiMock.getUsers.mockRejectedValue(new Error('Network error'));

// Mock delayed response
apiMock.getUsers.mockImplementation(
  () => new Promise(resolve => 
    setTimeout(() => resolve([{id: 1}]), 100)
);

Testing callback-style asynchronous code:

test('should test callback', done => {
  fs.readFile('/path', 'utf8', (err, data) => {
    expect(data).toBe('expected content');
    done();
  });
  
  // Trigger callback
  process.nextTick(() => 
    fs.readFile.mock.calls[0][2](null, 'expected content')
  );
});

Performance Considerations for Mocks and Stubs

While mocks and stubs can improve test speed, the following should be noted:

1. Initialization Overhead: Complex mock setups can increase test startup time.
2. Maintenance Cost: When mocked interfaces change, all related tests need to be updated.
3. Test Value: Over-mocking may prevent tests from discovering real integration issues.

Balancing recommendations:

• Unit tests: Use mocks and stubs extensively.
• Integration tests: Reduce mocks, use real dependencies.
• E2E tests: Avoid mocks, use the complete system.

Debugging Techniques for Mocks and Stubs

When tests fail, mock states can be inspected:

console.log(mockFn.mock.calls);  // View all call records
console.log(mockFn.mock.results); // View all return results

Jest also provides detailed mock diagnostic information:

expect(mockFn).toHaveBeenCalledTimes(3);
expect(mockFn).toHaveBeenLastCalledWith('expected-arg');

For complex mocking scenarios, auto-mocking can be temporarily disabled:

jest.dontMock('some-module');

Type Safety for Mocks and Stubs

In TypeScript projects, mock types must be kept correct:

const mockService: jest.Mocked<UserService> = {
  getUser: jest.fn().mockResolvedValue({id: 1, name: 'Test'})
} as any; // Sometimes type assertions are needed

// Better approach is to use utility types
type Mocked<T> = { [P in keyof T]: jest.Mock<T[P]> };
const mockService: Mocked<UserService> = {
  getUser: jest.fn()
};

For Sinon stubs:

const stub = sinon.stub<[number], Promise<User>>();
stub.resolves({id: 1, name: 'Test'});

Edge Cases for Mocks and Stubs

Special scenarios require extra attention:

1. Mocking ES6 Classes: Both the class and prototype methods need to be mocked.
2. Mocking Constructors: Instance creation needs to be tracked.
3. Mocking Third-Party Libraries: Version compatibility must be considered.

// Mocking class example
jest.mock('./Logger', () => {
  return jest.fn().mockImplementation(() => ({
    log: jest.fn(),
    error: jest.fn()
  }));
});

const Logger = require('./Logger');
const logger = new Logger();

test('should mock class', () => {
  logger.log('message');
  expect(Logger).toHaveBeenCalled();
  expect(logger.log).toHaveBeenCalledWith('message');
});

Common Pitfalls for Mocks and Stubs

1. Forgetting to Restore Mocks: Leads to test pollution.
2. Over-Specifying Verification: Makes tests too fragile.
3. Ignoring Asynchronicity: Failing to handle asynchronous mocks correctly.
4. Mocking Too Many Layers: Loses test value.

// Anti-pattern: Over-specifying
expect(mockFn).toHaveBeenCalledWith(
  expect.objectContaining({
    id: expect.any(Number),
    name: expect.stringMatching(/^[A-Z]/)
  })
);

// Better approach: Only verify necessary parts
expect(mockFn).toHaveBeenCalledWith(
  expect.objectContaining({ id: 1 })
);

Evolution Strategies for Mocks and Stubs

As projects evolve, testing strategies need to be adjusted:

1. Early Stage: Use mocks extensively to quickly establish test coverage.
2. Mid Stage: Gradually replace mocks with real implementations for critical paths.
3. Late Stage: Focus on strengthening integration tests, reducing mocks in unit tests.

Metrics for monitoring test health:

• Ratio of mocks to real implementations.
• Frequency of test failures due to interface changes.
• Number of production defects discovered by tests.