A Falácia dos Testes com Mocks Absolutos

O problema

Tem time que descobre mock, gosta da velocidade e conclui uma coisa perigosa:

se mock acelera e isola, então o melhor cenário é mockar tudo.

Soa disciplinado.

Na prática, pode virar um teatro bem organizado.

A suíte fica:

• rápida
• previsível
• cheia de testes verdes

E mesmo assim continua sem tocar em partes onde o sistema realmente quebra.

O nome do problema aqui não é “usar mock”.

É acreditar que um sistema inteiro pode ser validado só por encenações controladas.

Modelo mental

Pense assim:

mock absoluto cria um laboratório perfeito demais para revelar defeitos do mundo real.

Esse é o centro da falácia.

Quanto mais o ambiente de teste é desenhado para cooperar com a sua hipótese, maior a chance de você provar só uma coisa:

que o seu roteiro artificial funciona quando nada relevante sai do script.

Sistema real quase nunca te dá esse luxo.

Quebrando o problema

Mock útil corta ruído

Há vários casos em que mock ajuda bastante:

• relógio não é o foco
• gateway externo deixaria o feedback lento
• fila real não precisa participar para validar uma regra local

Aqui o isolamento compra foco.

Nada de errado nisso.

Mock absoluto corta justamente o atrito que revelaria o bug

Quando você mocka:

• persistência
• contrato HTTP
• formato do evento
• erro de dependência
• timeout
• retry

ao mesmo tempo, você remove do teste várias superfícies onde defeitos reais costumam nascer.

O teste fica confortável.

O sistema continua vulnerável.

O perigo não é só técnico. É cognitivo

Essa parte é importante.

Suíte excessivamente mockada ensina o time a confiar num tipo de evidência fraca.

O raciocínio vira:

• “tem teste”
• “o pipeline está verde”
• “então deve estar protegido”

Mas protegido contra o quê?

Muitas vezes, contra nada além de uma regressão dentro do próprio arranjo artificial de mocks.

Teste roteirizado demais costuma confirmar coreografia

Você vê isso quando o teste depende de:

• chamada X depois chamada Y
• método A exatamente três vezes
• sequência interna toda definida antes

Nesse ponto, a suíte está menos interessada no comportamento final e mais interessada em verificar se a implementação dançou a coreografia esperada.

Isso é frágil.

E pior: pode passar mesmo quando a costura real está errada.

Nem toda confiança deve morar na base da pirâmide

Esse é um erro comum em times que tentam resolver tudo com teste muito isolado.

A base rápida é importante.

Mas algumas perguntas só são respondidas quando você sobe de camada:

• o payload realmente bate com o contrato?
• o dado persistiu?
• o erro externo foi tratado como esperado?
• o fluxo real continua fechando?

Se nenhuma dessas perguntas aparece na suíte, você não tem estratégia. Tem preferência.

Exemplo simples

Imagine um caso de uso que:

1. valida entrada
2. salva pedido
3. publica evento
4. chama serviço de estoque

Suíte com mocks absolutos:

• repositório sempre aceita qualquer dado
• publicador sempre “publica”
• cliente HTTP sempre retorna sucesso
• validação falsa aceita exatamente o cenário feliz

O que essa suíte prova?

Que o seu serviço chama alguns colaboradores sob condições idealizadas.

O que ela não prova?

• se o pedido realmente persiste
• se o evento sai com formato correto
• se o contrato com estoque continua compatível
• se erro externo vira comportamento correto

Ela valida o teatro.

Não o fluxo real.

Erros comuns

• Chamar de “boa cobertura” uma suíte que só exercita dublês cooperativos.
• Usar mock para esconder dificuldade de montar integração útil.
• Tratar qualquer contato com ambiente real como se fosse sempre desperdício.
• Confundir velocidade com qualidade de evidência.
• Defender um dogma de testes em vez de olhar o risco do sistema.

Como um senior pensa

Quem tem mais repertório costuma fazer uma pergunta muito boa:

“Se eu trocasse meus mocks por comportamentos mais próximos do real, este teste continuaria sendo convincente?”

Se a resposta for não, o teste provavelmente estava apoiado demais em um cenário artificial.

Senioridade aqui aparece quando a pessoa quer evidência honesta, não só pipeline bonito.

O que o entrevistador quer ver

Em entrevista, esse tema mede maturidade de estratégia.

O entrevistador quer perceber se você:

• entende o valor de mocks sem tratá-los como religião
• sabe falar de confiança falsa
• enxerga quando precisa subir para integração ou fluxo real
• pensa em risco, não só em velocidade

Uma resposta forte pode soar assim:

“Eu uso mock para isolar o que não é a pergunta principal do teste. Mas eu não tento provar o sistema inteiro com um mundo fake. Se o risco mora em persistência, contrato, rede ou publicação de evento, alguma parte da suíte precisa tocar isso de forma mais honesta. Senão eu só provo que meus dublês obedecem ao roteiro.”

Mock absoluto não elimina risco. Só elimina atrito suficiente para o bug não aparecer.

Quando todo teste é confortável demais, a produção vira o primeiro ambiente sincero.