Testing the Adapter functional layer in React

The Adapter is a functional layer from Clean Architecture. It contains code that communicates with the outside world.

For instance:

• Employs fetch or axios
• Interacts with the AWS client or supabase
• Calls a server action (e.g., in the Nextjs project)
• Contains any other code with a side effect (out-of-process dependency)

export async function fetchProductById(id: string) {
    const response = await axios.get<Product>(
        `/api/product/${id}`,
        { headers: { 'Accept-Language': 'de-AT' } },
    );
  
    return response.data;
}        

Writing a unit test for a code that consumes a side effect is complex because we must mock the out-of-process dependency.

jest.mock('axios');
const mock = axios as jest.Mocked<typeof axios>;

describe('fetchProductById', () => {
    it('fetches product by identity', async () => {
        mock.get.mockResolvedValue({
            data: { id: 'x', name: 'y' }, 
            status: 200,
        });
  
        const result = await fetchProductById('x');
    
        expect(mock).toHaveBeenCalledWith(
            '/api/product/x', 
            { headers: { 'Accept-Language': 'de-AT' } },
        );
        expect(result).toBe({ id: 'x', name: 'y' });
    });
});        

Mocking inner code structure always leads to a brittle test. The test will break when we replace the side effect with an alternative (e.g., fetch to axios). It's not a good test.

An effective test is resilient to the implementation. It should break only when software behavior changes. Not when the code behind the implementation is refactored. It’s also known as a black-box test.

To make the test simple (mockless), we could enable passing a fake side effect. For example, via the options parameter.

async function fetchRequest(
    url: string, 
    config?: RequestConfig,
) {
    const response = await axios.get<Product>(url, config);
  
    return response.data;
}

export async function fetchProductById(
    id: string, 
    options?: Options,
) {
    const request = options?.request ?? fetchRequest;
    const response = await request(
        `/api/product/${id}`,
        { headers: { 'Accept-Language': 'de-AT' } },
    );
  
    return response.data;
}        

A slight change in the implementation design significantly simplifies testing.

describe('fetchProductById', () => {
    it('fetches product by identity', async () => {
        const fake = () => Promise.resolve({
            id: 'x', 
            name: 'y',
        });
  
        const result = await fetchProductById('x', {
            request: fake,
        });
    
        expect(fake).toHaveBeenCalledWith(
            '/api/product/x',
            { headers: { 'Accept-Language': 'de-AT' } },
        );
        expect(result).toBe({ id: 'x', name: 'y' });
    });
});        

Now, replacing the mechanism that communicates with the outside world is easy. The test will break only when we mess up the behavior of the Adapter function.

Lesson learned:

Implementation design impacts testing. Testing forces design to scale.