MockzillaMockzilla

Terminologia

Atualizado em 29 de set. de 2026·5 min de leitura

Todo produto acaba criando um vocabulário. Esta página diz o que o nosso significa, e por que a gente escolheu estas palavras e não outras.

Simulação

Uma simulação é uma cópia em funcionamento de um serviço: ela vive na própria URL e responde como o original. A gente fala simulação e não mock de propósito. Um mock é uma resposta falsa amarrada dentro de um teste. Uma simulação se comporta: gera dados válidos a partir dos seus schemas, valida o que você manda, injeta latência e erro, consegue encaminhar para o serviço real e cair no mock quando ele está fora, e guarda estado onde o serviço real guardaria. O caso mais claro é um backend resiliente rodando um cenário: um pagamento que você autoriza agora, captura depois e estorna na semana que vem é uma conversa com estado, não uma resposta fixa. sim é a mesma palavra, só que mais curta; você encontra ela no app e nas URLs.

Spec

O documento OpenAPI que descreve uma API. A palavra é do mercado, não nossa, e a gente manteve. O spec é a fonte da verdade aqui: tudo que uma simulação serve sai dele, então atualizar o spec é como você muda a simulação.

Serviço

Uma API dentro de uma simulação. Uma simulação pode servir vários serviços lado a lado, do mesmo jeito que o seu sistema em produção fala com várias dependências; uma sim de app é exatamente essa composição. Chama serviço porque é isso que ele é para o seu código: a coisa que ele chama.

Um serviço pode chamar outro serviço? Pode: um handler de codegen é código Go comum, e código Go comum chama o endpoint que precisar, inclusive o de um serviço irmão.

Num repo, cada serviço é um diretório de specs; o diretório services do template portable traz dois.

Dois serviços no template portable, um diretório cada.

Endpoint

Um método e um caminho que um serviço responde. A maioria é gerada a partir das operações do spec. Os endpoints estáticos são o outro tipo: um método, um caminho, um status e um corpo fixos que você escreve na mão, para aquela resposta exata que um teste precisa. Estáticos porque nunca variam.

Replay

Uma resposta real, gravada uma vez e servida de volta nas requisições que corresponderem. Replay porque nada é inventado: o que o upstream falou de verdade toca de novo. Você configura o que gravar e como as requisições são comparadas; o tráfego reproduzido aparece no Histórico como todo o resto.

Veja Gravar e ver replays.

Histórico

O registro de cada chamada que uma simulação respondeu: método, caminho, status, duração, e se a resposta veio do mock ou do upstream. Um nome simples para uma coisa simples.

Contexto

Valores com nome que guiam os dados gerados. Sem um, um campo gerado é tecnicamente válido e obviamente falso; um contexto entrega os valores realistas, moedas, nomes de estabelecimento, formatos de id. É aqui também que o Mockzilla se separa dos outros serviços de mock: você controla o que uma resposta contém com poucas linhas de YAML. Sem IA, sem token, sem dataset pré-gerado, sem nenhuma outra mágica, e a mesma requisição continua recebendo o mesmo tipo de resposta. Nos backends resilientes um contexto são valores YAML usados no lugar do que o provedor entrega. Contexto porque é o conhecimento em volta que o gerador lê na hora de preencher um campo.

Cenário

Uma regra quando/então em um backend resiliente: quando uma requisição corresponde a um gatilho, um valor específico, um número de cartão mágico, uma palavra-chave, então vem um resultado roteirizado, um código de recusa, um timeout, um caso mandado para análise. Os provedores fazem o mesmo com número de cartão de teste; a diferença é que aqui o roteiro é você que escreve. Cenário porque você está ensaiando uma situação, não devolvendo uma resposta fixa.

Backend resiliente

Um substituto direto do sandbox de um provedor de pagamento ou de identidade. Os endpoints, os formatos de resposta e os códigos de status são os do provedor, então a sua integração não muda nada além da URL base. Resiliente é a promessa que está no nome: ele fica de pé quando o sandbox do provedor está fora, limitado, ou não consegue produzir a falha que você precisa testar.

Backend

A sua própria instância da API de um provedor, e a palavra curta que o app usa para um backend resiliente. Você aponta a sua integração para ele igual faria com o sandbox do provedor. A diferença é de quem ele é. Ele é seu: você decide o que ele responde, e nenhum outro teste divide ele com você.

Uma coleção curada de specs de APIs públicas, prontas para deploy como simulações. Você navega, escolhe, e recebe uma URL.

Portable e codegen

Os dois jeitos de entregar uma simulação a partir de um repo. Portable empacota os seus specs do jeito que estão; portable porque o mesmo pacote roda em qualquer lugar, a nossa nuvem, o seu notebook, o Docker. O pacote é um arquivo .mockz, e qualquer simulação pode ser baixada como um e rodada localmente. Codegen gera handlers Go tipados a partir do seu spec para você adicionar lógica de verdade; o nome é literalmente o que ele faz.

Veja Simulações portable e Simulações codegen.

Esta página ajudou?