Forem: Leonardo Giraldi Moreno Giuranno

Simplificando testes com react-select-event

Leonardo Giraldi Moreno Giuranno — Wed, 07 Aug 2024 11:09:34 +0000

A squad em que atuo faz uso do componente react-select para apresentação de campos de seleção de alguns formulários em nossas aplicações frontend. Encontramos dificuldades para implementar testes utilizando a biblioteca React Testing Library que validassem o comportamento deste campo complexo em nossos componentes.

Estávamos seguindo por uma abordagem de tentar manipular os elementos gerados pelos componentes fornecidos pelo react-select através dos métodos utilitários do React Testing Library. Porém, não obtivemos sucesso e o código dos testes estavam cada vez mais obtendo uma complexidade desnecessária.

Ao consultar a documentação do próprio React Testing Library, mais especificamente na seção do ecossistema da biblioteca, nos deparamos com a lib "react-select-event":

Segundo sua descrição: "react-select-event é uma biblioteca complementar para a React Testing Library que fornece métodos auxiliares para interagir com elementos react-select.".

EUREKA!

No exemplo apresentado logo de cara, tínhamos um campo de seleção simples, que tinha como "fonte de dados" um simples array que era passado via prop options:

Este exemplo não era suficiente para nós, uma vez que nossos campos react-select consultam uma API para retornar a lista de opções com base no que foi digitado pelo usuário, ou seja, temos um cenário assíncrono em questão.

Acessamos então o repositório no GitHub da biblioteca em busca de mais exemplos.

No repositório, encontramos diversos exemplos de implementação, inclusive aquele que precisávamos:

Vamos dar uma olhada em um exemplo prático:

Considere o seguinte componente que implementa um formulário simples com apenas um campo de seleção:

import { useState } from "react";
import AsyncSelect from "react-select/async";

import { ColourOption, colourOptions } from "../data";
import { SingleValue } from "react-select";

const Form: React.FC = () => {
  const [selectedOption, setSelectedOption] = useState<string>();

  const filterColors = (inputValue: string) => {
    return colourOptions.filter((i) =>
      i.label.toLowerCase().includes(inputValue.toLowerCase())
    );
  };

  const promiseOptions = (inputValue: string) =>
    new Promise<ColourOption[]>((resolve) => {
      setTimeout(() => {
        resolve(filterColors(inputValue));
      }, 1000);
    });

  const handleChange = (option: SingleValue<ColourOption>) => {
    if (option) {
      setSelectedOption(option.label);
    }
  };

  return (
    <form>
      <label htmlFor="color">Cor</label>
      <AsyncSelect
        defaultOptions
        loadOptions={promiseOptions}
        name="color"
        onChange={handleChange}
        inputId="color"
      />
      <p>Cor selecionada: {selectedOption}</p>
    </form>
  );
};

export { Form };

Utilizando somente os recursos disponíveis no React Testing Library, seguiríamos pelo caminho de tentar manipular diretamente o valor do input:

import { fireEvent, render, screen } from "@testing-library/react";

import { Form } from "../../components/Form";

describe("Form", () => {
  it("should present selected color", async () => {
    render(<Form />);

    const input = screen.getByLabelText("Cor");
    fireEvent.change(input, { target: { value: "purple" } });

    expect(
      await screen.findByText("Cor selecionada: Purple")
    ).toBeInTheDocument();
  });
});

Ou tentaríamos simular o preenchimento do campo e, após, a seleção da opção via seta para baixo e tecla enter:

import { fireEvent, render, screen } from "@testing-library/react";

import { Form } from "../../components/Form";

describe("Form", () => {
  it("should present selected color", async () => {
    render(<Form />);

    const input = screen.getByLabelText("Cor");
    fireEvent.change(input, { target: { value: "purple" } });
    fireEvent.keyDown(input, { key: "ArrowDown", code: "ArrowDown" });
    fireEvent.keyDown(input, { key: "Enter", code: "Enter" });

    expect(
      await screen.findByText("Cor selecionada: Purple")
    ).toBeInTheDocument();
  });
});

Estes foram os caminhos que tentamos trilhar. Porém, somente tivemos êxito quando adotamos o react-select-event. Com ele, o teste fica assim:

import { render, screen } from "@testing-library/react";
import selectEvent from "react-select-event";

import { Form } from "../../components/Form";

describe("Form", () => {
  it("should present selected color", async () => {
    render(<Form />);

    const input = screen.getByLabelText("Cor");
    await selectEvent.select(input, "Purple");

    expect(
      await screen.findByText("Cor selecionada: Purple")
    ).toBeInTheDocument();
  });
});

A biblioteca ainda disponibiliza outros métodos além do select que podem atender a outros cenários de teste que você necessite implementar:

Depois desta pequena jornada, ficamos com uma lição: "se a solução está ficando complexa, é grande a chance de estarmos trilhando o caminho errado".

Mocks agnósticos para bibliotecas de requisições HTTP no Node.js

Leonardo Giraldi Moreno Giuranno — Mon, 23 Oct 2023 11:30:00 +0000

Desde que comecei a implementar testes unitários para os projetos e aplicações que estava envolvido, configurava o mock das bibliotecas de requisições HTTP individualmente. Por exemplo, se eu utilizasse o axios para fazer chamadas a outras APIs, durante a implementação dos testes, eu configurava o mock do axios em si. Vamos dar uma olhadinha nessa implementação:

Considere a seguinte função:

const axios = require("axios");

async function fetchCep(cep) {
        const { data } = await axios.get(`https://viacep.com.br/ws/${cep}/json/`);
    return data;
}

module.exports = {
      fetchCep,
};

A simples função fetchCep(cep) utiliza a biblioteca axios para fazer uma solicitação HTTP GET para um serviço de consulta de CEP (Código de Endereçamento Postal) fornecido pela API do ViaCEP. O objetivo desta função é obter informações de endereço com base em um CEP fornecido como argumento.

Agora vamos implementar o teste unitário que valida se a função fetchCep retorna as informações do CEP fornecido obtidas na API do ViaCEP:

const mockAxiosGet = jest.fn();
jest.mock("axios", () => ({
    get: mockAxiosGet,
}));

const { fetchCep } = require("./axiosMockExample");

describe("fetchCep", () => {
    it("should return cep information", async () => {
        mockAxiosGet.mockResolvedValueOnce({
            data: {
                cep: "12345678",
                logradouro: "Avenida Paulista",
                bairro: "Centro",
                localidade: "São Paulo",
                uf: "SP",
            },
        });
        const cep = "12345678";

        const result = await fetchCep(cep);

        expect(result.cep).toBe("12345678");
        expect(result.logradouro).toBe("Avenida Paulista");
        expect(result.bairro).toBe("Centro");
        expect(result.localidade).toBe("São Paulo");
        expect(result.uf).toBe("SP");
    });
});

Em um primeiro momento, estamos configurando o mock da biblioteca axios e de sua função get:

const mockAxiosGet = jest.fn();
jest.mock("axios", () => ({
      get: mockAxiosGet,
}));

Logo em seguida, realizamos a importação da nossa função fetchCep :

const { fetchCep } = require("./axiosMockExample");

O primeiro passo do teste “should return cep information" é configurar o retorno do método get da biblioteca axios:

mockAxiosGet.mockResolvedValueOnce({
    data: {
        cep: "12345678",
        logradouro: "Avenida Paulista",
        bairro: "Centro",
        localidade: "São Paulo",
        uf: "SP",
    },
});

Configurado o retorno do método get, realizamos a chamada à nossa função fetchCep e validamos se obtivemos o retorno esperado:

const cep = "12345678";

const result = await fetchCep(cep);

expect(result.cep).toBe("12345678");
expect(result.logradouro).toBe("Avenida Paulista");
expect(result.bairro).toBe("Centro");
expect(result.localidade).toBe("São Paulo");
expect(result.uf).toBe("SP");

Agora, basta executarmos nosso teste utilizando o jest:

Excelente! Nosso teste passou como esperado! 🥳

Porém, e se, por algum motivo, necessitamos alterar a biblioteca de requisições HTTP que estamos utilizando atualmente, o axios? O que aconteceria com nosso teste implementado? Vamos conferir?

Suponhamos que a biblioteca axios foi trocada pela Fetch API nativa do Node.js:

async function fetchCep(cep) {
    const response = await fetch(`https://viacep.com.br/ws/${cep}/json/`);

    return response.json();
}

module.exports = {
    fetchCep,
};

Vamos agora executar nosso teste unitário:

Como podemos ver, nosso teste passou a falhar. O motivo da falha está relacionado ao fato de termos configurado um mock completamente preso à biblioteca que utilizávamos anteriormente, o axios.

Para solucionarmos essa dependência utilizaremos a biblioteca [Mock Service Worker (MSW)](https://mswjs.io/). Essa biblioteca é uma ferramenta que permite simular e interceptar solicitações de rede em aplicativos web e Node.js durante os testes. Ela fornece uma maneira conveniente de criar mocks para as respostas de chamadas de rede, permitindo que os desenvolvedores controlem o comportamento das solicitações HTTP feitas pelo aplicativo em testes unitários, sem realmente realizar solicitações à rede real. Isso é especialmente útil para isolar testes e garantir que o aplicativo funcione corretamente, mesmo quando a API ou os serviços externos não estão disponíveis, enquanto também simplifica a simulação de diferentes cenários de respostas de rede para fins de teste.

Agora, vamos configurar o service worker em nosso arquivo de testes. Para isso, precisamos instalar o pacote do MSW em nossas dependências de desenvolvimento utilizando o npm ou yarn:

npm install msw --save-dev

No arquivo de testes, vamos importar o objeto rest do pacote msw e a função setupServer do pacote msw/node:

const { setupServer } = require("msw/node");
const { rest } = require("msw");

Antes da declaração da nossa suite de testes, o describe, vamos configurar nosso server, o qual será responsável por interceptar todas as chamas realizadas por qualquer biblioteca de requisições HTTP:

const server = setupServer(
    rest.get("https://viacep.com.br/ws/:cep/json/", (req, res, ctx) => {
        return res(
            ctx.status(200),
            ctx.json({
                cep: "12345678",
                logradouro: "Avenida Paulista",
                bairro: "Centro",
                localidade: "São Paulo",
                uf: "SP",
            })
        );
    })
);

Como podemos ver, estamos configurando o comportamento do interceptor para requisições HTTP do tipo GET no endpoint https://viacep.com.br/ws/:cep/json/. Note que em :cep, estamos abstraindo qualquer CEP que seja fornecido durante a requisição HTTP. A configuração realizada retornará o status code 200 e o objeto contendo as informações do CEP no corpo da resposta.

Para mais informações sobre possibilidades de configuração de interceptores, recomendo consultarem a documentação oficial do MSW.

Estamos quase lá! Precisamos, das seguintes configurações:

Antes de todos os testes da suite, inicializar nosso servidor:

beforeAll(() => server.listen());

Após cada teste da suite, restaurar a configuração original do nosso servidor, definida acima. Essa restauração garante que, caso adicionemos novos handlers ou sobrescrevemos os existentes dentro dos testes, a configuração do servidor seja a original antes de cada teste ser executado dentro de nossa suite:

afterEach(() => server.resetHandlers());

Após todos os testes da suite, encerrar nosso servidor:

afterAll(() => server.close());

Os últimos dois pontos a serem alterados em nosso arquivo de testes é a remoção do mock da biblioteca axios e da configuração do retorno do seu método get:

// REMOVER
const mockAxiosGet = jest.fn();
jest.mock("axios", () => ({
    get: mockAxiosGet,
}));

...

// REMOVER
mockAxiosGet.mockResolvedValueOnce({
    data: {
        cep: "12345678",
        logradouro: "Avenida Paulista",
        bairro: "Centro",
        localidade: "São Paulo",
        uf: "SP",
    },
});

Finalmente, a nossa implementação do teste ficará assim:

const { setupServer } = require("msw/node");
const { rest } = require("msw");
const { fetchCep } = require("./axiosMockExample");

const server = setupServer(
    rest.get("https://viacep.com.br/ws/:cep/json/", (req, res, ctx) => {
        return res(
            ctx.status(200),
            ctx.json({
                cep: "12345678",
                logradouro: "Avenida Paulista",
                bairro: "Centro",
                localidade: "São Paulo",
                uf: "SP",
            })
        );
    })
);

describe("fetchCep", () => {
    beforeAll(() => server.listen());

    afterEach(() => server.resetHandlers());

    afterAll(() => server.close());

    it("should return cep information", async () => {
        const cep = "12345678";

        const result = await fetchCep(cep);

        expect(result.cep).toBe("12345678");
        expect(result.logradouro).toBe("Avenida Paulista");
        expect(result.bairro).toBe("Centro");
        expect(result.localidade).toBe("São Paulo");
        expect(result.uf).toBe("SP");
    });
});

Agora, temos nosso teste passando com sucesso:

Neste exemplo, nos baseamos em uma requisição HTTP do tipo GET. Porém, a biblioteca MSW permite configurarmos interceptores para todos os verbos HTTP.

Recomendo fortemente o estudo da documentação oficial da biblioteca para implementação dos testes de seus projetos e aplicações.

Library-Agnostic Mocks for HTTP Request Libraries in Node.js

Leonardo Giraldi Moreno Giuranno — Mon, 23 Oct 2023 11:30:00 +0000

Since I started implementing unit tests for the projects and applications I was involved in, I used to set up the mock for HTTP request libraries individually. For instance, if I was using axios to make calls to other APIs, during test implementation, I would configure the axios mock itself. Let's take a look at this implementation:

Consider the following function:

const axios = require("axios");

async function fetchCep(cep) {
        const { data } = await axios.get(`https://viacep.com.br/ws/${cep}/json/`);
    return data;
}

module.exports = {
      fetchCep,
};

The simple function fetchCep(cep) uses the axios library to make an HTTP GET request to a ZIP code lookup service provided by the ViaCEP API. The purpose of this function is to retrieve address information based on a provided ZIP code as an argument.

Now, let's implement the unit test that validates whether the fetchCep function returns the provided ZIP code information obtained from the ViaCEP API:

const mockAxiosGet = jest.fn();
jest.mock("axios", () => ({
    get: mockAxiosGet,
}));

const { fetchCep } = require("./axiosMockExample");

describe("fetchCep", () => {
    it("should return cep information", async () => {
        mockAxiosGet.mockResolvedValueOnce({
            data: {
                cep: "12345678",
                logradouro: "Avenida Paulista",
                bairro: "Centro",
                localidade: "São Paulo",
                uf: "SP",
            },
        });
        const cep = "12345678";

        const result = await fetchCep(cep);

        expect(result.cep).toBe("12345678");
        expect(result.logradouro).toBe("Avenida Paulista");
        expect(result.bairro).toBe("Centro");
        expect(result.localidade).toBe("São Paulo");
        expect(result.uf).toBe("SP");
    });
});

At first, we are setting up the mock for the axios library and its get function.

const mockAxiosGet = jest.fn();
jest.mock("axios", () => ({
      get: mockAxiosGet,
}));

Right after that, we import our fetchCep function:

const { fetchCep } = require("./axiosMockExample");

The first step in the "should return cep information" test is to set up the return value of the get method of the axios library:

mockAxiosGet.mockResolvedValueOnce({
    data: {
        cep: "12345678",
        logradouro: "Avenida Paulista",
        bairro: "Centro",
        localidade: "São Paulo",
        uf: "SP",
    },
});

Once the get method's return value is configured, we call our fetchCep function and validate whether we received the expected result:

const cep = "12345678";

const result = await fetchCep(cep);

expect(result.cep).toBe("12345678");
expect(result.logradouro).toBe("Avenida Paulista");
expect(result.bairro).toBe("Centro");
expect(result.localidade).toBe("São Paulo");
expect(result.uf).toBe("SP");

Now, we simply run our test using Jest:

Great! Our test passed as expected! 🥳

However, what if, for some reason, we need to change the HTTP request library we are currently using, like axios? What would happen to our implemented test? Let's find out?

Let's assume that the axios library has been replaced with the native Fetch API of Node.js:

async function fetchCep(cep) {
    const response = await fetch(`https://viacep.com.br/ws/${cep}/json/`);

    return response.json();
}

module.exports = {
    fetchCep,
};

Now, let's run our unit test:

As we can see, our test has now failed. The reason for the failure is related to the fact that we had configured a mock that was tightly coupled to the library we were using previously, axios.

To resolve this dependency, we will use the Mock Service Worker (MSW) library. This library is a tool that allows you to simulate and intercept network requests in web applications and Node.js during testing. It provides a convenient way to create mocks for the responses of network calls, enabling developers to control the behavior of HTTP requests made by the application in unit tests without actually making requests to the real network. This is especially useful for isolating tests and ensuring that the application functions correctly even when the API or external services are unavailable, while also simplifying the simulation of different network response scenarios for testing purposes.

Now, let's set up the service worker in our test file. To do this, we need to install the MSW package in our development dependencies using npm or yarn:

npm install msw --save-dev

In the test file, we'll import the rest object from the msw package and the setupServer function from the msw/node package:

const { setupServer } = require("msw/node");
const { rest } = require("msw");

Before the declaration of our test suite using describe, let's set up our server, which will be responsible for intercepting all calls made by any HTTP request library:

const server = setupServer(
    rest.get("https://viacep.com.br/ws/:cep/json/", (req, res, ctx) => {
        return res(
            ctx.status(200),
            ctx.json({
                cep: "12345678",
                logradouro: "Avenida Paulista",
                bairro: "Centro",
                localidade: "São Paulo",
                uf: "SP",
            })
        );
    })
);

As we can see, we are configuring the interceptor's behavior for GET requests to the endpoint https://viacep.com.br/ws/:cep/json/. Note that in :cep, we are abstracting any ZIP code provided during the HTTP request. The configuration set will return a status code of 200 and the object containing ZIP code information in the response body.

For more information on configuring interceptors, I recommend consulting the official MSW documentation.

We're almost there! We need the following configurations:

Before all tests in the suite, initialize our server:

beforeAll(() => server.listen());

After each test in the suite, restore the original configuration of our server, as defined above. This restoration ensures that if we add new handlers or overwrite existing ones within the tests, the server's configuration is the original one before each test is executed within our suite:

afterEach(() => server.resetHandlers());

After all tests in the suite, shut down our server:

afterAll(() => server.close());

The last two points to change in our test file are the removal of the mock for the axios library and the configuration of the return of its get method:

// REMOVER
const mockAxiosGet = jest.fn();
jest.mock("axios", () => ({
    get: mockAxiosGet,
}));

...

// REMOVER
mockAxiosGet.mockResolvedValueOnce({
    data: {
        cep: "12345678",
        logradouro: "Avenida Paulista",
        bairro: "Centro",
        localidade: "São Paulo",
        uf: "SP",
    },
});

Finally, our test implementation will look like this:

const { setupServer } = require("msw/node");
const { rest } = require("msw");
const { fetchCep } = require("./axiosMockExample");

const server = setupServer(
    rest.get("https://viacep.com.br/ws/:cep/json/", (req, res, ctx) => {
        return res(
            ctx.status(200),
            ctx.json({
                cep: "12345678",
                logradouro: "Avenida Paulista",
                bairro: "Centro",
                localidade: "São Paulo",
                uf: "SP",
            })
        );
    })
);

describe("fetchCep", () => {
    beforeAll(() => server.listen());

    afterEach(() => server.resetHandlers());

    afterAll(() => server.close());

    it("should return cep information", async () => {
        const cep = "12345678";

        const result = await fetchCep(cep);

        expect(result.cep).toBe("12345678");
        expect(result.logradouro).toBe("Avenida Paulista");
        expect(result.bairro).toBe("Centro");
        expect(result.localidade).toBe("São Paulo");
        expect(result.uf).toBe("SP");
    });
});

Now, our test is passing successfully:

In this example, we focused on an HTTP GET request. However, the MSW library allows us to configure interceptors for all HTTP verbs.

I strongly recommend studying the official documentation of the library for implementing tests in your projects and applications.

Mocking imported Python modules implementation

Leonardo Giraldi Moreno Giuranno — Mon, 19 Sep 2022 00:32:05 +0000

This week, while I was developing an improvement in our team’s Ansible project, I was caught by a challenge: how to prevent any code snippet from a python module from running other than the function you are importing into the unit test target module, class or function?

The scenario encountered was during the development of a custom module for Ansible. As I was developing in a Windows environment, an Ansible dependency had problems during the import in the module ansible.module_utils.basic:

# Copyright (c), Michael DeHaan <michael.dehaan@gmail.com>, 2012-2013
# Copyright (c), Toshio Kuratomi <tkuratomi@ansible.com> 2016
# Simplified BSD License (see licenses/simplified_bsd.txt or https://opensource.org/licenses/BSD-2-Clause)

from __future__ import absolute_import, division, print_function
__metaclass__ = type

FILE_ATTRIBUTES = {
    'A': 'noatime',
    'a': 'append',
    'c': 'compressed',
    'C': 'nocow',
    'd': 'nodump',
    'D': 'dirsync',
    'e': 'extents',
    'E': 'encrypted',
    'h': 'blocksize',
    'i': 'immutable',
    'I': 'indexed',
    'j': 'journalled',
    'N': 'inline',
    's': 'zero',
    'S': 'synchronous',
    't': 'notail',
    'T': 'blockroot',
    'u': 'undelete',
    'X': 'compressedraw',
    'Z': 'compresseddirty',
}

# Ansible modules can be written in any language.
# The functions available here can be used to do many common tasks,
# to simplify development of Python modules.

import __main__
import atexit
import errno
import datetime
import grp
import fcntl
import locale
import os
import pwd
import platform
import re
import select
import shlex
import shutil
import signal
import stat
import subprocess
import sys
import tempfile
import time
import traceback
import types

The package that had the error was grp.

At the time of implementing the unit tests of my custom module, it was not relevant for me to fix this problem, since any and all functions that I would consume from the ansible.module_utils.basic module would be mocked.

For this, I spent a few hours researching a way out of this scenario. Here I come across the following solution: using the sys module, I should create a mock of the module file in question. That way, when I run my unit tests, the import in the form from … import … would not execute any code snippet from the module ansible.module_utils.basic.

Let's exemplify this solution with a very simple scenario:

We have the following Python project:

├── custom_module
│   ├── __init__.py
│   ├── module_a.py
│   ├── module_b.py
└── tests
    ├── __init__.py
    └── test_module_b.py

Function function b of module module b makes a call to function function_a of module module_a. For this, module_b needs to import the module module_a. Let's take a look at the implementation of the two modules:

# custom_module/module_a.py

def function_a():
    print("I'm the function A")

raise Exception("some generic error in module a")

# custom_module/module_b.py

from custom_module.module_a import function_a

def function_b():
    print("I'm the function B")
    function_a()

I know it's very strange for a module to simply have an exception throw, but to simulate the “defective” module, this implementation of module_a is enough.

Let's now take a look at the implemented unit test:

# tests/test_module_b.py

import unittest
from unittest.mock import patch, call

from custom_module.module_b import function_b

class TestModuleB(unittest.TestCase):
    def setUp(self):
        self.patch_builtins_print = patch("builtins.print")
        self.mock_builtins_print = self.patch_builtins_print.start()

    def tearDown(self):
        self.patch_builtins_print.stop()

    def test_should_print_function_b_msg(self):
        expected_calls = [
            call("I'm the function B")
        ]

        function_b()

        self.mock_builtins_print.assert_has_calls(expected_calls)

At the beginning of the file, we are importing, in the sequence:

unittest: a module dedicated to implementing the Python unit tests;
patch e call: functions that are used for mocking objects, functions and calls;
function_b: a function from module_b, which we want to test.

In the configuration function of our test scenarios, called setUp, we are mocking the native print python function (print) and the function_a of the module_a that is “broken”. This configuration function is executed before each implemented test scenario of the TestModuleB class.

The tearDown function is the function that is executed after each implemented test scenario of the TestModuleB class and it is responsible for resetting the mocks configured in the setUp function.

Our test scenario is the test_should_print_function_b_msg function and we define in it within the expected_calls variable which are the calls we expect from the print function and which parameter is passed to it.

The way our mini project is implemented, if we run our test scenario, we will have the following result:

$ python3 -m unittest discover -v
tests.test_module_b (unittest.loader._FailedTest) ... ERROR

======================================================================
ERROR: tests.test_module_b (unittest.loader._FailedTest)
----------------------------------------------------------------------
ImportError: Failed to import test module: tests.test_module_b
Traceback (most recent call last):
  File "/usr/lib/python3.10/unittest/loader.py", line 436, in _find_test_path
    module = self._get_module_from_name(name)
  File "/usr/lib/python3.10/unittest/loader.py", line 377, in _get_module_from_name
    __import__(name)
  File "/home/leogiraldimg/repos/mock-imported-python-modules-implementation/tests/test_module_b.py", line 4, in <module>
    from custom_module.module_b import function_b
  File "/home/leogiraldimg/repos/mock-imported-python-modules-implementation/custom_module/module_b.py", line 1, in <module>
    from custom_module.module_a import function_a
  File "/home/leogiraldimg/repos/mock-imported-python-modules-implementation/custom_module/module_a.py", line 4, in <module>
    raise Exception("some generic error in module a")
Exception: some generic error in module a

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (errors=1)

As we can see, the module_a exception is thrown and prevents our unit test from running successfully.

To fix this problem, we need to mock the module_a as follows:

import sys
import unittest
from unittest.mock import MagicMock, patch, call

sys.modules["custom_module.module_a"] = MagicMock()
from custom_module.module_b import function_b

class TestModuleB(unittest.TestCase):
    def setUp(self):
        self.patch_builtins_print = patch("builtins.print")
        self.mock_builtins_print = self.patch_builtins_print.start()

    def tearDown(self):
        self.patch_builtins_print.stop()

    def test_should_print_function_b_msg(self):
        expected_calls = [
            call("I'm the function B")
        ]

        function_b()

        self.mock_builtins_print.assert_has_calls(expected_calls)

The first step is to import the Python module sys and through it mock the import of the module_a file in sys.modules["custom_module.module_a"] = MagicMock(). Here we are using the MagicMock class from the mock unit testing utility.

Now, we have the following result:

$ python3 -m unittest discover -v
test_should_print_function_b_msg (tests.test_module_b.TestModuleB) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.001s

OK

We can further improve our code by moving the mock from module_a to a file dedicated only to these needs:

# tests/test_module_b.py

import unittest
from unittest.mock import MagicMock, patch, call

import tests.mock_modules
from custom_module.module_b import function_b

class TestModuleB(unittest.TestCase):
    def setUp(self):
        self.patch_builtins_print = patch("builtins.print")
        self.mock_builtins_print = self.patch_builtins_print.start()

    def tearDown(self):
        self.patch_builtins_print.stop()

    def test_should_print_function_b_msg(self):
        expected_calls = [
            call("I'm the function B")
        ]

        function_b()

        self.mock_builtins_print.assert_has_calls(expected_calls)

# tests/mock_modules.py

import sys
from unittest.mock import MagicMock

sys.modules["custom_module.module_a"] = MagicMock()