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.

Recently, I have been learning how to develop REST APIs using Express and how to write tests for them. As part of my learning journey, I have also been exploring TypeScript ORMs capable of handling streams.

A stream is a sequence of data elements made available over time, used for handling large volumes of data or continuous data flow. Streams are useful because they allow for efficient processing of data chunks as soon as they are available, without waiting for the entire data set. This is particularly helpful in managing resources and improving performance in applications like real-time data feeds, file processing, and network communications.

Streams can be particularly useful in various scenarios, such as:

File Processing: When handling large files, streams can read and process data in chunks, preventing memory overload and enabling efficient data handling.
Network Communications: Streams are ideal for handling data over network requests and responses, such as in web APIs, where data can be processed as it arrives rather than waiting for the complete set.
Real-time Data Feeds: For applications like social media feeds, stock tickers, or live sports updates, streams allow for real-time processing and display of incoming data.
Audio/Video Streaming: Media streaming services use streams to deliver content in a buffered manner, enabling smooth playback while the rest of the data is being received.
Data Transformation: In ETL (Extract, Transform, Load) operations, streams can efficiently process and transform data before it's loaded into a database or another system.
Log Processing: For applications that generate large volumes of logs, streams can help in efficiently reading and processing log data for monitoring or analytics.
Chat Applications: Streams enable the implementation of real-time messaging features in chat applications, handling continuous data flow between users.

For this purpose, I created the blog-orm repository, which showcases how to interact with a PostgreSQL database using TypeORM and return data as a stream.

For creating the DB Post table you just need to implement a Post.ts entity and data-source.ts:

//entity/Post.ts
import { Entity, PrimaryGeneratedColumn, Column } from "typeorm"

@Entity()
export class Post {
    @PrimaryGeneratedColumn()
    id: number

    @Column()
    title: string

    @Column()
    content: string

    @Column()
    isPublished: boolean
}

//data-source.ts
import "reflect-metadata"
import { DataSource } from "typeorm"
import { Post } from "./entity/Post"

export const AppDataSource = new DataSource({
    type: "postgres",
    host: "localhost",
    port: 5432,
    username: "postgres",
    password: "postgres",
    database: "blog",
    synchronize: true,
    logging: false,
    entities: [Post],
    migrations: [],
    subscribers: [],
})

A service could look like that:

//postService.ts
import { AppDataSource } from "./data-source";
import { Post } from "./entity/Post";

export async function getAllStream() {
    return await AppDataSource.getRepository(Post).createQueryBuilder("post").stream();
}

And finally the controller:

//controller.ts
import { Request, Response, NextFunction } from "express";
import * as postService from "./postService"
import { pipeline } from "stream/promises";
import Disassembler from 'stream-json/Disassembler';
import Stringer from 'stream-json/Stringer';

export async function getAllStream(req: Request, res: Response, next: NextFunction) {
    try {
        const stream = await postService.getAllStream();
        res.setHeader('Content-Type', 'application/json');
        const tokenizer = new Disassembler();
        const jsonStream = new Stringer({ makeArray: true });
        pipeline(stream, tokenizer, jsonStream, res)
    } catch (error) {
        console.error(error);
        res.status(500).send('An error occurred');
    }
}

And that's the whole magic! You can find the complete code in this repository.

abelcastro.dev

Avoiding Mocks in Testing Through Single Responsibility and Dependency Injection

How to Create an Express + TypeORM REST API and Return Data as a Stream

Sports Dashboard

Bad Example: Hard-coded Dependency

Testing the Bad Example

Good Example: Single Responsibility and Dependency Injection

Testing the Good Example

Conclusion

The API

Upting the data

Conclusion