Teste a API do Claude Fable 5.2 com Apidog: Testes de Regressão

Para testar integrações com a API Claude Fable 5.2, valide a autenticação, o corpo da requisição de Messages, os blocos de resposta tipados e as falhas previsíveis. Em seguida, salve essas verificações como casos de teste repetíveis do Apidog que o seu agente de código executa pela CLI. Mantenha as asserções de transporte separadas das verificações de qualidade da tarefa, para que uma resposta HTTP bem-sucedida não esconda uma resposta inutilizável.

O anúncio da Anthropic identifica claude-fable-5-2 como o ID do modelo na plataforma Claude. Este guia constrói um fluxo de trabalho de regressão em torno desse modelo, em vez de parar após uma única resposta bem-sucedida. O Apidog oferece ao seu agente um local compartilhado para manter o endpoint, os casos de teste e os relatórios de execução.

O que os testes da API Claude Fable 5.2 devem cobrir?

Use três camadas: as verificações de transporte estabelecem se a requisição chegou ao serviço; as verificações de contrato validam a estrutura da resposta; as verificações comportamentais estabelecem se a sua aplicação consegue usar o resultado. Execute as duas primeiras para cada fixture. Defina critérios comportamentais de aceitação para cada tarefa em vez de comparar respostas geradas inteiras byte a byte.

Comece com um fixture mínimo e inofensivo: “Quanto é 2 + 2? Responda apenas com o numeral.” Ele torna a regra de aceitação visível sem introduzir arquivos, ferramentas ou histórico de conversa. Adicione fixtures representativos da aplicação depois que o contrato básico funcionar.

Não trate esse fixture como um benchmark de raciocínio. O objetivo dele é detectar regressões de integração, como extrair um bloco de pensamento como texto voltado ao usuário ou aceitar uma resposta truncada.

Defina a autenticação e as configurações da requisição antes de testar

Para a API Claude direta, use o endpoint de Messages, uma credencial de API com escopo de workspace, uma versão explícita da API e um corpo de requisição fixo. Mantenha essas entradas constantes entre as execuções. A visão geral da API documenta a autenticação Bearer, a seleção do workspace e os cabeçalhos de versão. Essas configurações diferem da autenticação IAM de provedores de nuvem.

Use uma chave de API do Claude Console fornecida por meio do seu ambiente local de segredos. Um token de acesso do Apidog autentica a CLI junto ao Apidog; ele não autentica requisições à Anthropic. Mantenha as duas credenciais separadas.

A requisição a seguir segue a documentação atual de Messages, verificada em 10 de novembro de 2026. Salve o JSON como request.json:

{
  "model": "claude-fable-5-2",
  "max_tokens": 1024,
  "stream": false,
  "thinking": { "type": "adaptive" },
  "messages": [
    {
      "role": "user",
      "content": "What is 2 + 2? Reply with the numeral only."
    }
  ]
}

Depois, envie-a pelo seu terminal ou faça com que o seu agente de código a execute:

curl https://api.anthropic.com/v1/messages \
  -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
  -H 'anthropic-version: 2026-10-21' \
  -H 'Content-Type: application/json' \
  --max-time 600 \
  --dump-header response.headers \
  --output response.json \
  --write-out '%{http_code}\n' \
  --data-binary @request.json

Se a sua chave não tiver escopo de workspace, inclua o cabeçalho documentado anthropic-workspace-id para o workspace de destino. Nunca coloque uma credencial literal no fixture salvo nem em um relatório gerado.

A referência de criação de mensagem define model, messages e max_tokens, além dos campos da mensagem retornada. Aqui, 1.024 é um orçamento de saída escolhido, não um mínimo documentado nem uma garantia de que toda tarefa caberá nele. Aumente-o deliberadamente quando um fixture precisar de mais espaço.

Este é um modelo verificado pela documentação. Execute-o com a sua própria conta de API autorizada antes de registrar uma linha de base aprovada; nenhuma resposta real do Fable ou medição de latência é reivindicada aqui.

Adicione asserções de resposta que resistam à variação gerada

Valide o envelope, inspecione os tipos de blocos, extraia o texto e, então, aplique a regra de aceitação do fixture. Uma resposta de Messages contém um array content, portanto não presuma que content[0].text contém a resposta. Preserve a mensagem original completa separadamente, caso a sua aplicação a reenvie em turnos posteriores da conversa.

Para o fixture aritmético, peça ao seu agente para anexar este script pós-resposta ao caso de teste do Apidog:

pm.test("HTTP success", function () {
  pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("Assistant message contract", function () {
  pm.expect(body.type).to.eql("message");
  pm.expect(body.role).to.eql("assistant");
  pm.expect(body.id).to.be.a("string");
  pm.expect(body.model).to.be.a("string");
  pm.expect(body.content).to.be.an("array");
});

const text = body.content
  .filter(block => block.type === "text")
  .map(block => block.text)
  .join("\n").trim();

pm.test("Arithmetic fixture is complete", function () {
  pm.expect(body.stop_reason).to.eql("end_turn");
  pm.expect(text).to.eql("4");
});

A igualdade exata faz sentido para esse numeral deliberadamente restrito. Para um resumo, use critérios como fatos obrigatórios, alegações não fundamentadas proibidas e limites de comprimento. Uma mudança inofensiva na redação não deveria quebrar um teste de resumo útil.

Registre usage e o cabeçalho request-id da resposta para diagnóstico. Compare os identificadores de modelo retornados com o comportamento documentado para o identificador escolhido; não rotule silenciosamente respostas de fallback como resultados do Fable.

Um motivo de parada max_tokens significa que a resposta atingiu o limite de saída. Faça esse fixture aritmético falhar e inspecione o orçamento de tokens. Outras tarefas podem legitimamente retornar motivos de parada diferentes, incluindo solicitações de ferramentas, portanto dê a cada caso sua própria regra de conclusão.

Teste os casos negativos da API Claude Fable 5.2

Crie um caso separado para cada entrada inválida e altere um campo por vez. Verifique o status HTTP e o tipo de erro estruturado em vez de comparar a mensagem de erro legível completa. Mantenha a linha de base válida inalterada para que um fixture negativo não contamine a próxima execução positiva.

O guia oficial de erros documenta os seguintes casos úteis:

O Fable 5.2 usa thinking sempre ativado. Não copie um tutorial antigo do Claude que o desativa ou configura orçamentos de extended thinking. O caso de thinking desativado é especialmente útil ao atualizar código compartilhado de construção de requisições.

Para cada caso de erro, verifique body.type === "error", o body.error.type esperado e uma mensagem de erro não vazia. Preserve um ID de requisição quando disponível. Trate falhas de DNS e timeouts do cliente como resultados separados, pois podem nunca produzir um erro JSON do Claude.

Teste o tratamento de limites de taxa e falhas de serviço da sua aplicação com fixtures controlados ou um mock. Não sobrecarregue a API real para fabricar um 429. Distinga problemas de capacidade retentáveis de falhas de autenticação e validação, e estabeleça um orçamento finito de tentativas em torno da lógica de retry da sua aplicação.

Deixe o seu agente de código construir os casos de regressão do Apidog

Forneça ao seu agente o endpoint, os fixtures, as asserções e o projeto de destino. Ele pode descobrir o esquema atual da CLI, validar cada payload, criar casos de teste e executá-los. Você revisa os casos gerados e o resumo das falhas. Isso mantém o fluxo de trabalho repetível no Apidog CLI.

Instale a CLI e autentique-se com o seu token do Apidog:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_APIDOG_TOKEN>

Para configurar o agente, siga os guias atualizados para Claude Code ou Codex. Depois, dê ao seu agente um único prompt:

In Apidog project <PROJECT_ID>, define POST /v1/messages for the
Claude API. Use model claude-fable-5-2 and version 2026-10-21.
Keep the Anthropic credential in a private runtime variable.
Create the arithmetic success case and four negative cases above.
Read CLI help and input schemas before generating payloads.
Discover valid endpoint and category IDs; validate every payload.
Attach the response assertions, then run each case against
<ENVIRONMENT_ID>. Report failures, request IDs, and token usage.
Do not print credentials or claim unexecuted cases passed.

Os comandos a seguir foram verificados com a CLI 2.2.12 instalada. O agente precisa de um ID de endpoint real e um ID de categoria; o test-case-create descreve casos derivados de endpoints, portanto criar uma requisição JSON independente não relacionada não é suficiente.

apidog test-case category --project <PROJECT_ID>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <PROJECT_ID> --file case.json
apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json

Faça com que o agente examine a ajuda e os esquemas do comando de endpoint quando o endpoint não existir. Use os IDs retornados, não números ilustrativos copiados de outro projeto. Valide o case.json antes de salvá-lo e, em seguida, leia o caso criado de volta para confirmar que os cabeçalhos, o corpo e as asserções pretendidos foram salvos.

Execute testes de regressão da API Claude em CI

Execute os mesmos casos após alterações na autenticação, na serialização de mensagens, na análise de blocos ou no tratamento de retry. Exporte relatórios legíveis por máquina e mantenha a versão do fixture junto com a alteração da sua aplicação. Estabeleça uma linha de base aprovada antes de fazer comparações e, então, investigue as falhas individualmente em vez de executar novamente até que o build, por acaso, passe.

Para um caso já criado no Apidog, uma invocação orientada a CI é:

apidog run --test-case <CASE_ID> --project <PROJECT_ID> \
  -e <ENVIRONMENT_ID> -r cli,json,junit \
  --out-dir ./apidog-reports

Repita para os outros IDs de casos ou deixe que o seu agente organize os casos em uma suíte de testes usando o esquema atual de suítes. O guia de CI/CD do Apidog aborda a integração com pipelines.

Mantenha o modelo, a versão da API, o corpo da requisição, o orçamento de saída, a revisão do fixture e a versão da CLI no registro de execução. Armazene as credenciais por meio do mecanismo de segredos do seu CI. Revise os relatórios quanto a dados sensíveis de requisições antes de compartilhá-los.

Use um pequeno conjunto de smoke tests reais para mudanças rotineiras e um conjunto comportamental mais amplo antes dos lançamentos. Defina os seus próprios orçamentos de gastos e duração. Uma aprovação no contrato da API estabelece compatibilidade de integração; os seus testes de aceitação específicos da aplicação estabelecem se a saída é útil.

FAQ

Qual ID de modelo devo testar?

Use claude-fable-5-2 para este fluxo de trabalho direto da plataforma Claude. Verifique a disponibilidade na sua conta antes de salvar uma linha de base.

O HTTP 200 é suficiente para aprovar?

Não. Verifique o envelope da mensagem, o conteúdo tipado, o motivo de conclusão e os critérios de aceitação do fixture. Streaming exige verificações adicionais no nível de eventos, pois falhas podem ocorrer depois que os cabeçalhos da resposta chegam.

Posso desativar o thinking do Fable 5.2?

Não. A Anthropic documenta o thinking sempre ativado para este modelo. Mantenha o thinking desativado como um caso negativo que espera um erro de validação.

Todas as respostas devem corresponder exatamente?

Use correspondências exatas para fixtures restritos, como o exemplo do numeral. Para tarefas abertas, defina critérios factuais e estruturais que permitam variações válidas na redação.

O meu agente pode executar os testes novamente após uma correção?

Sim. Forneça a ele os IDs dos casos salvos e o ambiente e, então, faça-o executar os mesmos comandos da CLI e resumir os relatórios. Comece pelo fluxo de trabalho da CLI com Claude Code se precisar configurar o agente.