Se você escreve testes de frontend, provavelmente já se deparou com o Mock Service Worker (MSW). É a biblioteca ideal para interceptar requisições dentro do navegador e do Node, e para testes de unidade e de componente é difícil de superar. Este guia explica o que o MSW faz bem, onde ele para de escalar e quando uma plataforma de mocking de API hospedada faz mais sentido.
botão
O que é Mock Service Worker?
Mock Service Worker é uma biblioteca JavaScript que intercepta requisições de rede na origem. No navegador, ele registra um Service Worker que intercepta chamadas fetch e XMLHttpRequest. No Node, ele corrige a camada de requisições para que os mesmos manipuladores sejam executados no Jest ou Vitest. Você escreve manipuladores de requisição que correspondem a um método e caminho e, em seguida, retorna a resposta que desejar.
O design é inteligente. Seu código de aplicação continua chamando as APIs de rede reais. O MSW fica no meio e responde, então você não precisa fazer stub de fetch ou trocar seu cliente HTTP. As mesmas definições de mock funcionam em testes e em um build de desenvolvimento em execução, e é por isso que tantas equipes de React e Vue o utilizam. Você pode se aprofundar no código-fonte do MSW no GitHub para ver como a camada de interceptação funciona.
Um manipulador típico se parece com isto:
import { http, HttpResponse } from 'msw'
export const handlers = [
http.get('/api/users/:id', ({ params }) => {
return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' })
}),
]
Esse é todo o apelo. O mock vive ao lado do seu código, é versionado com seus testes e é executado onde quer que seu JavaScript seja executado.
Onde o MSW se destaca
O MSW é uma ótima opção quando o mock e o consumidor vivem na mesma base de código. Alguns casos em que é genuinamente a ferramenta certa:
- Testes de componente e unidade. Renderize um componente, deixe-o disparar suas requisições reais e retorne dados pré-definidos. Não há duplos de teste para configurar. Se você está comparando com a espionagem direta do cliente, veja como isso difere de um mock Jest de uma chamada de API.
- Desenvolvimento frontend local. Construa a UI antes que o backend exista. Alterne os manipuladores para simular carregamento, erros ou estados vazios sob demanda.
- CI determinístico. Os testes não acessam um servidor ativo, então não falham devido a condições de rede ou dados de staging compartilhados.
- Uma linguagem, uma equipe. Quando as pessoas que escrevem o mock são as pessoas que o consomem, manter os manipuladores no repositório é o caminho mais simples.
Se essa é a sua situação, você provavelmente não precisa de mais nada. O MSW é gratuito, de código aberto e construído exatamente para isso.
Onde o MSW começa a apresentar dificuldades
A mesma coisa que torna o MSW ótimo em um único repositório, mocks que vivem como código nesse repositório, é o que o limita quando mais pessoas se envolvem. É aqui que as equipes tendem a superá-lo.
Consumidores não-JavaScript
Os manipuladores do MSW são JavaScript. Se sua equipe mobile escreve em Swift ou Kotlin, ou seus testes de integração de backend são executados em Go ou Python, eles não podem importar seus manipuladores. Eles precisariam de seus próprios mocks, que se desviariam dos seus. Um servidor de mock agnóstico à linguagem que se comunica via HTTP por uma URL real funciona para qualquer cliente, independentemente da linguagem.
Mocks compartilhados e sempre ativos
O MSW é executado dentro de um processo. Não há uma URL compartilhada que um engenheiro de QA, um designer ou uma equipe parceira possa acessar de sua própria máquina. No momento em que você deseja um endpoint que várias pessoas usam ao mesmo tempo, você precisa de um servidor de mock hospedado com um endereço estável, e não um Service Worker vinculado a uma única aba do navegador.
Workflows "design-first" e orientados por esquema
Se você projeta APIs em OpenAPI antes de escrever o código, você deseja mocks gerados automaticamente a partir da especificação, para que o mock não discorde do contrato. O MSW espera que você escreva manipuladores manualmente. Gerar mocks diretamente de um esquema é um modelo diferente. Você pode ler mais sobre essa abordagem neste guia de mocking de API e os padrões relacionados.
Dados realistas e dinâmicos em escala
O MSW retorna o que quer que seu manipulador codifique. Para dados realistas em muitos campos, você escreve essa lógica sozinho. Plataformas que incorporam geração estilo faker e inferência de nomes de campos fornecem respostas realistas sem que você precise criar cada uma manualmente.
MSW vs uma plataforma completa de mocking de API
Aqui está uma comparação honesta. Nenhuma coluna é "melhor" em abstrato; elas resolvem problemas diferentes.
| Capacidade | Mock Service Worker | Plataforma de API hospedada (ex: Apidog) |
|---|---|---|
| Executa dentro de testes de unidade/componente JS | Sim, nativo | Não, não é uma biblioteca de testes JS |
| Agnóstico à linguagem via HTTP | Não (somente JS) | Sim, qualquer cliente |
| URL compartilhada para toda a equipe | Não | Sim, servidor de mock hospedado |
| Gera mocks a partir do OpenAPI | Manual | Automático a partir do esquema |
| Geração de dados inteligentes/dinâmicos | Codificado manualmente | Integrado |
| Vive no seu repositório com testes | Sim | Armazenado em projeto compartilhado |
| Custo | Gratuito, código aberto | Camada gratuita + planos pagos |
A conclusão: o MSW é a escolha certa para testes de frontend e desenvolvimento local. Uma plataforma como o Apidog é a escolha certa quando o mock precisa ser compartilhado, agnóstico à linguagem ou impulsionado por uma especificação.
Apidog como complemento, não substituto
Para ser claro, o Apidog não é um substituto direto para o MSW dentro do Jest ou Vitest. Não é uma biblioteca JavaScript que você importa para um arquivo de teste. Trate-o como a camada acima dos seus testes de unidade, o local onde os mocks se tornam um recurso compartilhado e agnóstico à linguagem para toda a equipe.
Veja como isso funciona na prática. Você projeta ou importa uma API no Apidog, e ele gera um endpoint de mock automaticamente a partir do esquema. O mock obtém uma URL real que seus colegas de equipe de frontend, mobile e QA podem todos chamar. O Apidog preenche as respostas com dados realistas inferindo a partir dos nomes dos campos, então um campo chamado email retorna um e-mail e createdAt retorna uma data. Você também pode escrever regras personalizadas quando precisar de uma resposta 500 específica ou de um caso de borda particular.
Como o mock vem do mesmo esquema do seu design e testes, ele permanece sincronizado com o contrato. Essa é a parte que os manipuladores escritos à mão não podem garantir. Se você quiser ver como a geração de esquema para mock se compara entre as ferramentas, este resumo das melhores ferramentas de mocking de API coloca as opções lado a lado.
Uma divisão prática que muitas equipes adotam:
- Mantenha o MSW para testes de componente e unidade dentro do repositório frontend.
- Use um mock hospedado para integração entre equipes, demonstrações e qualquer consumidor não-JS.
Você não está escolhendo um. Você está usando cada um onde ele se encaixa. Baixe o Apidog se quiser experimentar o lado hospedado junto com sua configuração MSW existente.
Outras alternativas ao MSW que valem a pena conhecer
O MSW não é a única biblioteca de mocking, e uma plataforma não é sua única opção. Dependendo da sua stack:
- Mockoon é um aplicativo de desktop para iniciar servidores de mock locais rapidamente, com uma GUI em vez de código.
- WireMock é um servidor de mock baseado em Java, forte para equipes JVM e testes de contrato.
- Prism da Stoplight gera um mock diretamente de um arquivo OpenAPI via linha de comando.
- json-server transforma um arquivo JSON em uma API REST rápida para prototipagem.
Cada um tem suas vantagens e desvantagens. WireMock e Prism se inclinam para o trabalho de backend e contrato; Mockoon e json-server se inclinam para uma configuração local rápida. Se o seu problema é especificamente "o MSW não consegue ajudar meus colegas de equipe que não usam JS", qualquer servidor de mock baseado em HTTP resolve isso. Para um ângulo de frontend mais amplo, veja como as equipes lidam com o mocking de APIs em React com Axios.
Perguntas Frequentes
O MSW é gratuito?
Sim. O Mock Service Worker é de código aberto sob a licença MIT e gratuito para uso em qualquer projeto, comercial ou não. Você só começa a pagar quando migra para uma plataforma hospedada para mocks compartilhados, e ferramentas como o Apidog também incluem um plano gratuito para isso.
O Apidog pode substituir o MSW nos meus testes de unidade?
Não, e você não deve tentar fazer isso. O MSW intercepta requisições dentro do seu test runner JavaScript. O Apidog é uma plataforma hospedada, não uma biblioteca importável, então ele não pode funcionar dentro do Jest ou Vitest da mesma forma que o MSW. Use o Apidog para mocks compartilhados, entre equipes ou orientados por esquema. Se você está focado puramente no lado do test runner, este guia sobre como fazer mock de chamadas de API cobre as abordagens baseadas em código.
O MSW funciona no Node, ou apenas no navegador?
Ambos. No navegador, o MSW usa um Service Worker. No Node, ele corrige a camada de requisições para que os mesmos manipuladores sejam executados no Jest, Vitest ou em qualquer ambiente de teste Node. Esse modo duplo é uma de suas maiores forças para equipes JS full-stack.
Quando devo mudar do MSW para um servidor de mock hospedado?
Mude, ou melhor, adicione um, quando o mock precisar ser compartilhado. Os sinais mais claros: um cliente não-JavaScript precisa dele, várias pessoas precisam da mesma URL estável, ou você projeta APIs com base em especificações e deseja que os mocks sejam gerados automaticamente a partir do OpenAPI.
Conclusão
O MSW é excelente no que foi construído para fazer: interceptar requisições dentro do JavaScript para testes de frontend e de unidade. Ele não tenta ser um mock compartilhado, hospedado e agnóstico à linguagem, e isso está tudo bem. Quando seus mocks precisam sair do repositório, quando outras linguagens ou outras equipes precisam deles, ou quando você deseja que eles sejam gerados a partir de uma especificação, esse é o momento de adicionar uma plataforma completa ao lado dele.
O Apidog lida com o lado compartilhado e orientado por esquema: um servidor de mock hospedado com uma URL real, mocks automáticos a partir do seu design OpenAPI e dados realistas prontos para uso. Mantenha o MSW onde ele é forte e deixe o Apidog cobrir tudo o que vai além da borda do seu test runner. Baixe o Apidog e aponte seu frontend para um mock compartilhado para ver a diferença.
botão