abelcastro.dev

I personally hate to use mocks or spies when I write tests. Often they make tests more fragile, unclear and unreliable. Personally a way that I learned to avoid them is to adhere to principles like Single Responsibility Principle (SRP) and Dependency Injection (DI). 

One way to reduce the need for mocks is by designing your code with principles like Single Responsibility Principle (SRP) and Dependency Injection (DI). This makes the code more modular, easier to test, and less reliant on mocks.

Let me show you what I am talking about with 2 examples:

Bad Example: Hard-coded Dependency

Consider a TypeScript class that directly creates and uses an external library or service within its methods. This tight coupling makes it difficult to test without resorting to mocks.

class EmailService {
    sendEmail(to: string, subject: string, body: string) {
        // Directly using an external email sending library
        const emailClient = new ExternalEmailClient();
        emailClient.configure();
        emailClient.send(to, subject, body);
    }
}

Testing the Bad Example

To test the bad example, you'd typically need to use a library that supports mocking global objects or constructors, which can be cumbersome and lead to brittle tests. However, TypeScript itself doesn't directly support mocking like some dynamic languages do, so you'd have to rely on a JavaScript testing framework that allows such operations, like Jest.

Here's an illustrative example using Jest to mock ExternalEmailClient: In this example, EmailService is directly dependent on ExternalEmailClient. To test EmailService's sendEmail method, you would have to mock ExternalEmailClient, which complicates the test setup.

// Assume ExternalEmailClient is imported from somewhere
jest.mock('./ExternalEmailClient', () => {
  return jest.fn().mockImplementation(() => {
    return {
      configure: jest.fn(),
      send: jest.fn(),
    };
  });
});

describe('EmailService', () => {
  it('should send an email using ExternalEmailClient', () => {
    const emailService = new EmailService();
    emailService.sendEmail('test@example.com', 'Test Subject', 'Test Body');
    // Assertions to verify that ExternalEmailClient was called correctly
    // This part is highly dependent on the mocking framework's API
  });
});

This approach has several downsides:

• It relies on global mocks, which can affect other tests if not properly isolated or reset.
• The test is more focused on implementation details (i.e., it tests whether ExternalEmailClient was called) rather than the outcome or behavior of the EmailService.

Good Example: Single Responsibility and Dependency Injection

A better approach is to refactor the code to follow the Single Responsibility Principle and use Dependency Injection. This way, each class has only one reason to change, and dependencies are injected rather than hard-coded.

interface IEmailClient {
    configure(): void;
    send(to: string, subject: string, body: string): void;
}

class EmailService {
    private emailClient: IEmailClient;

    constructor(emailClient: IEmailClient) {
        this.emailClient = emailClient;
    }

    sendEmail(to: string, subject: string, body: string) {
        this.emailClient.configure();
        this.emailClient.send(to, subject, body);
    }
}

class ExternalEmailClient implements IEmailClient {
    configure(): void {
        // Configuration logic for the external email client
    }

    send(to: string, subject: string, body: string): void {
        // Sending logic for the external email client
    }
}

Testing the Good Example

Testing the good example is more straightforward and doesn't typically require special mocking libraries. You can easily create a mock or stub that implements the IEmailClient interface and pass it to the EmailService constructor.

Here's an example using a simple mock object:

class MockEmailClient implements IEmailClient {
  configureCalled = false;
  sendCalledWith: [string, string, string] | null = null;

  configure(): void {
    this.configureCalled = true;
  }

  send(to: string, subject: string, body: string): void {
    this.sendCalledWith = [to, subject, body];
  }
}

describe('EmailService', () => {
  it('should send an email using the provided email client', () => {
    const mockEmailClient = new MockEmailClient();
    const emailService = new EmailService(mockEmailClient);
    emailService.sendEmail('test@example.com', 'Test Subject', 'Test Body');

    expect(mockEmailClient.configureCalled).toBe(true);
    expect(mockEmailClient.sendCalledWith).toEqual(['test@example.com', 'Test Subject', 'Test Body']);
  });
});

This testing approach has several advantages:

• It's clear and straightforward. The mock implementation is easy to understand and control.
• It focuses on the behavior rather than the implementation. You're testing that EmailService uses its IEmailClient dependency correctly, not how IEmailClient is implemented.
• It doesn't require any global mocking or special mocking frameworks, making the tests more reliable and less prone to interference.

Conclusion

The refactored (good) example not only adheres to the Single Responsibility Principle and employs Dependency Injection for better design but also significantly improves testability. Tests become more focused on behavior rather than implementation, are easier to write and understand, and are less brittle.