Secção Mocks
A secção Mocks é onde define as respostas simuladas que o MicroLab serve quando uma dependência é resolvida como mock. Permite-lhe trabalhar sem VPN e sem iniciar o core que o seu micro chama.
Não precisa de iniciar nada para editar mocks: o catálogo vive no disco
(.microlab/mocks/<serviço>.json) e é servido com recarga a quente, por isso uma
alteração aplica-se ao instante mesmo com o cenário em execução.
A árvore: serviços → endpoints
Seção intitulada “A árvore: serviços → endpoints”O lateral mostra uma árvore de serviços (os cores mockáveis) e, dentro de cada um, os seus endpoints. Os endpoints agrupam-se em pastas recolhíveis derivadas dos segmentos do seu caminho, sem que tenha de os organizar à mão.
Um serviço é mockável se for uma dependência de algum micro (ou se criar o seu ficheiro em
.microlab/mocks). Pode mostrar ou ocultar os serviços que ainda não têm stubs.
Criar um stub
Seção intitulada “Criar um stub”Prima Novo stub (ou o menu «⋮») e escolha o serviço de destino —um do catálogo ou um novo que se cria ao guardar—. Um endpoint define-se com:
- Método e caminho (relativo ao caminho base do serviço).
- Uma ou várias variantes de resposta.
Há duas formas de preencher o corpo:
- A partir de OpenAPI: se o serviço declarar uma especificação OpenAPI (no manifesto do micro, ou derivada do seu URL cloud), selecione a operação e o MicroLab gera um modelo do corpo.
- Manual: se não houver OpenAPI, escreve o corpo JSON à mão.
Variantes: a unidade de trabalho
Seção intitulada “Variantes: a unidade de trabalho”Um endpoint pode ter várias variantes (por exemplo uma 200 e uma 500). Cada variante
tem a sua etiqueta, código de estado, corpo (JSON), cabeçalhos e uma
latência opcional em milissegundos para simular lentidão.
A variante selecionada expande-se em linha com o seu corpo, cabeçalhos e ajustes juntos. A variante que se serve marca-se à parte com um comutador (é independente da que está a editar): é a resposta que o MicroLab devolverá a quem chamar esse endpoint.
Pode duplicar uma variante para partir de uma parecida, e ativar ou desativar um endpoint inteiro (um desativado não se serve nem se edita).
Guardado automático
Seção intitulada “Guardado automático”O editor de mocks guarda sozinho, com um pequeno atraso, enquanto escreve; verá um indicador «Guardado». Salvaguardas:
- Só se persistem estados válidos: um corpo JSON a meio não quebra o mock servido —mantém-se o último válido no disco e o erro marca-se em linha—.
- Um stub novo não se persiste até ter método e caminho utilizáveis.
- A eliminação é sempre explícita, com confirmação.
Mock Studio: de uma chamada real a um stub
Seção intitulada “Mock Studio: de uma chamada real a um stub”Quando um cenário corre e um micro chama um mock que ainda não tem resposta, essa chamada aparece no dock Chamadas mock. A partir daí pode criar um stub com um clique a partir da chamada observada: vai direto ao endpoint que quer completar, sem o procurar. Também pode testar o que o mock responderia sem iniciar nada.
Importar e exportar
Seção intitulada “Importar e exportar”Com os ícones de importar/exportar do painel:
- Exportar os endpoints de um serviço (ou de vários) para um ficheiro JSON.
- Importar um JSON próprio ou uma coleção Postman (as suas pastas mapeiam para serviços).
Útil para partilhar um catálogo de mocks ou reutilizá-lo entre cenários.
O mesmo a partir do CLI
Seção intitulada “O mesmo a partir do CLI”Tudo isto existe também no CLI: microlab mock services, mock catalog, mock save, mock set-active, mock skeleton, mock from-call, mock probe, mock import / export. Ver a
referência do CLI.