Escreva os seus próprios cenários
Os gatilhos que vêm junto cobrem os casos que todo time precisa. Os seus cobrem os que só o seu produto tem: o estorno que o seu time de finanças discute, o solicitante que as suas regras de risco tratam diferente, a resposta exata com que um relato de bug chegou.
Um cenário é um quando e um então: quando uma requisição corresponde ao que você descreve, o backend responde do jeito que você disse.
Onde eles vivem
Abra o backend, vá em Cenários, escolha um provedor e use a aba Este backend.
Cada linha é um cenário: um nome, uma ou mais condições, e o resultado. O nome é um rótulo. Ele volta junto com o resultado para você saber qual regra disparou, e ele nunca é usado para corresponder.
As condições da mesma linha são alternativas. Uma linha que corresponde a dois nomes dispara quando qualquer um dos dois chega, não quando os dois chegam.
Qual dispara
Três camadas, testadas em ordem:
- Os seus
- O que o provedor traz
- O conjunto compartilhado a que todo provedor responde
A primeira correspondência ganha, então escrever um cenário para insufficient_funds substitui o comportamento que vem junto para aquele gatilho e deixa todo o resto em paz.
Dentro de uma camada, o backend escolhe por uma ordem fixa de condições, não pela ordem em que as linhas aparecem na tela. Essa ordem está nas páginas de pagamentos e de identidade.
Para descartar as duas camadas que vêm junto e responder só pela sua lista, coloque replace: true.
Escrever YAML no lugar
O editor e o YAML são o mesmo documento. Troque para YAML para tudo que a tabela não expressa, ou para colar um cenário que alguém te mandou.
Voltar para o editor reescreve o documento, o que apaga os comentários. O app avisa antes.
As abas De fábrica e Compartilhado são o lugar óbvio para começar: copie uma entrada que já funciona e mude o que precisar.
O que é conferido antes de salvar
O seu documento é conferido contra o build que o backend roda de verdade, não contra o mais novo. Um backend fixado em um build mais antigo é medido pelo que aquele build aceita.
A conferência cobre o formato do documento, os nomes dos resultados, os motivos que vão com eles, e os campos pelos quais você pode corresponder. Tudo que ela não conseguir aceitar é reportado por linha, com a linha nomeada, e o salvamento é recusado.
Escopo
Cada sobrescrita pertence a um escopo de provedor, nos mesmos três níveis com que um backend escolhe provedores: uma marca, uma API dela, ou uma versão exata. O mais estreito ganha.
Escrever contra a marca costuma ser o certo. Vá para um escopo de versão quando duas versões da mesma API precisarem mesmo de respostas diferentes.
Colocar no ar
Salvar guarda o documento. Fazer deploy é o que coloca ele no backend no ar, igual a qualquer outra mudança.
Remover uma sobrescrita devolve aquele provedor ao que ele traz de fábrica.