Objetos Mock: o que são e como usar em testes

Objetos mock são objetos simulados que substituem dependências reais — como bancos de dados ou APIs — durante testes de unidade. Eles imitam o comportamento do componente original de forma controlada, permitindo isolar a unidade sob teste e verificar suas interações sem depender de infraestrutura externa.

• O que são objetos mock?
• Qual a diferença entre mock, stub, fake e spy?
• Por que usar objetos mock em testes de unidade?
• Como criar um objeto mock na prática?
• Quando usar e quando evitar objetos mock?

O que são objetos mock?

Objetos mock (ou apenas "mocks") são substitutos programáveis de objetos reais, criados especificamente para testes de software. Um mock imita a interface de uma dependência — um repositório, um cliente HTTP, um serviço de pagamento — e responde às chamadas com valores que você define, além de registrar como foi invocado. Isso permite exercitar uma unidade de código sem acionar o sistema real por trás dela.

O termo foi cunhado no artigo "Endo-Testing: Unit Testing with Mock Objects", de Tim Mackinnon, Steve Freeman e Philip Craig, apresentado na conferência XP 2000 — o nome é uma alusão à personagem "Mock Turtle" de Lewis Carroll (leia o paper original). A proposta era simples e poderosa: em vez de testar uma classe junto com todas as suas dependências, você troca essas dependências por dublês controlados e observa o comportamento de dentro.

Na prática, o objeto mock cumpre duas funções. Primeiro, devolve dados previsíveis — sempre o mesmo resultado, independentemente de rede, disco ou horário. Segundo, atua como um espião: ele sabe se o método esperado foi chamado, quantas vezes e com quais argumentos. Essa combinação torna os mocks peças centrais de um bom conjunto de testes de software, especialmente nos testes de unidade.

Qual a diferença entre mock, stub, fake e spy?

Mock é apenas um dos tipos de "test double" (dublê de teste). O termo genérico foi popularizado por Gerard Meszaros e detalhado por Martin Fowler no artigo Mocks Aren't Stubs: a distinção-chave é que um stub usa verificação de estado (você checa o resultado), enquanto um mock usa verificação de comportamento (você checa se as interações esperadas aconteceram).

A tabela abaixo resume os cinco dublês mais citados:

Na conversa do dia a dia, muitos desenvolvedores chamam qualquer dublê de "mock", e as bibliotecas reforçam isso. O importante é entender a intenção: se o teste deve confirmar que um método foi chamado com certos argumentos, você quer um mock; se só precisa de um valor de retorno, um stub basta.

Por que usar objetos mock em testes de unidade?

Objetos mock resolvem o problema central do teste de unidade: exercitar uma peça de código em isolamento, sem arrastar consigo o mundo inteiro. Ao substituir dependências pesadas por dublês controlados, você ganha testes rápidos, estáveis e fáceis de diagnosticar. Os três benefícios abaixo aparecem em praticamente todo projeto que adota a prática.

Isolamento de componentes

O mock garante que apenas a unidade em foco seja avaliada. Se o teste falha, o problema está no código testado — não em uma API (Interface de Programação de Aplicações) fora do ar ou em um banco de dados com dados inconsistentes. Esse isolamento aproxima o teste de unidade da ideia de testes de caixa branca, em que você conhece e controla o caminho interno da execução.

Eficiência e velocidade

Chamadas reais a bancos, filas ou serviços web custam milissegundos ou segundos e podem falhar por motivos externos. Um mock devolve a resposta instantaneamente e sempre da mesma forma, tornando a suíte determinística. Isso permite rodar milhares de testes em segundos, algo essencial para integração contínua e feedback rápido.

Manutenção simplificada

À medida que o software evolui, os testes precisam acompanhar. Com mocks, alterações no comportamento de uma dependência são refletidas em um único ponto de configuração do teste, sem exigir ambientes completos. Isso reduz o custo de manter a suíte viva e confiável ao longo do tempo.

Como criar um objeto mock na prática?

Suponha uma classe Pedido que depende de uma classe BancoDeDados para recuperar informações do usuário. Em vez de acessar o banco real, criamos um objeto mock que simula o método buscar, verificamos o resultado e mantemos o teste totalmente isolado. Veja como isso fica nas ferramentas mais populares.

Java com Mockito

O Mockito é descrito em seu repositório oficial como o "framework de mocking mais popular para testes unitários escritos em Java". Ele usa uma sintaxe fluente com mock(), when() e thenReturn():

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.*;
import org.junit.jupiter.api.Test;

class PedidoTest {
    @Test
    void calcularTotal_DeveRetornarTotalCorreto_QuandoUsuarioExiste() {
        // Configuração do mock
        BancoDeDados bancoMock = mock(BancoDeDados.class);
        when(bancoMock.buscar(anyInt())).thenReturn(new DadosUsuario(/* dados simulados */));

        // Execução
        Pedido pedido = new Pedido(bancoMock);
        double resultado = pedido.calcularTotalPedido(1);

        // Verificação de estado e de comportamento
        assertEquals(/* total esperado */, resultado);
        verify(bancoMock).buscar(1);
    }
}

Python com unittest.mock

Python traz o módulo unittest.mock na biblioteca padrão, sem instalar nada. A classe Mock cria dublês configuráveis via return_value, e assert_called_once_with verifica as interações:

from unittest.mock import Mock

def test_calcular_total_pedido_quando_usuario_existe():
    # Configuração do mock
    banco_mock = Mock()
    banco_mock.buscar.return_value = DadosUsuario()  # dados simulados

    # Execução
    pedido = Pedido(banco_mock)
    resultado = pedido.calcular_total_pedido(1)

    # Verificação
    assert resultado == 42  # total esperado
    banco_mock.buscar.assert_called_once_with(1)

JavaScript com Jest

No ecossistema JavaScript, o Jest oferece jest.fn() para funções mock e matchers como toHaveBeenCalledWith para verificação de comportamento:

test('calcularTotalPedido retorna total correto quando usuário existe', () => {
  // Configuração do mock
  const bancoMock = { buscar: jest.fn(() => new DadosUsuario(/* dados simulados */)) };

  // Execução
  const pedido = new Pedido(bancoMock);
  const resultado = pedido.calcularTotalPedido(1);

  // Verificação
  expect(resultado).toBe(42); // total esperado
  expect(bancoMock.buscar).toHaveBeenCalledWith(1);
});

O padrão se repete em outras linguagens: PHPUnit (createMock) no PHP, Moq (new Mock<T>()) no C#, Google Test/Google Mock (ON_CALL, EXPECT_CALL) no C++ e bibliotecas nativas no Ruby (RSpec). Muda a sintaxe, mas a receita é sempre a mesma: crie o dublê, defina as respostas e verifique as chamadas.

Quando usar e quando evitar objetos mock?

Objetos mock brilham quando a dependência real é lenta, instável, cara ou difícil de preparar: bancos de dados, APIs de terceiros, gateways de pagamento, envio de e-mail e relógios do sistema. Nesses casos, o mock transforma um teste frágil e demorado em um teste rápido e repetível — exatamente o que você quer numa suíte de unidade extensa.

Por outro lado, mockar demais é um antipadrão conhecido. Ao simular objetos simples que você mesmo controla, o teste passa a verificar detalhes de implementação em vez de comportamento observável, e qualquer refatoração legítima quebra dezenas de testes. Como regra prática: prefira objetos reais quando forem baratos, reserve mocks para as fronteiras do sistema e complemente com testes de integração para validar a comunicação de verdade.

Vale ainda ligar os mocks à sua estratégia de testes como um todo. Em abordagens como o desenvolvimento orientado por comportamento (BDD), os dublês ajudam a especificar interações esperadas antes mesmo de a implementação existir, mantendo o foco no que o software deve fazer. Aqui no CodeCrush recomendamos tratar o mock como uma ferramenta cirúrgica, não como o comportamento padrão de todo teste.

Conclusão

Objetos mock não são um truque para "passar no teste": são um instrumento de design que força você a pensar nas fronteiras e nas dependências do seu código. Bem usados, deixam a suíte de unidade veloz, determinística e fácil de diagnosticar; usados em excesso, acoplam os testes à implementação e viram peso morto. O bom desenvolvedor conhece a diferença entre mock, stub, fake e spy e aplica cada um com intenção — mockando as fronteiras externas e confiando em objetos reais e testes de integração para o resto.