Testando sua aplicação

Chamando sua API

curl funciona para uma verificação rápida:

curl -s -X POST http://localhost:8080/orders \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"customerId":"...","items":[{"price":100,"quantity":2}]}'

Para um fluxo de testes manuais mais elaborado — várias chamadas encadeadas, reaproveitando ids de respostas anteriores sem copiar e colar — um arquivo .http (suportado pela extensão REST Client do VS Code, entre outros clientes) é mais prático que uma sequência de curls soltos. Veja samples/03-inventory-orders/inventory.http no repositório do Pipevine para um exemplo real desse padrão.

Health checks

Os dois endpoints de saúde descritos em Implantação também servem para verificação manual durante o desenvolvimento:

curl -s http://localhost:8080/health/live    # 200 se o processo está de pé
curl -s http://localhost:8080/health/ready   # reflete conectividade real com as dependências

Um /health/ready retornando um status diferente de 200 antes de qualquer chamada de negócio é geralmente o sinal mais rápido de que uma dependência (Postgres, por exemplo) não está acessível — vale checar antes de investigar mais fundo.

Obtendo um token para testar rotas autenticadas

Sem um IdP real disponível, mintar um token de teste localmente é a forma mais rápida de exercitar uma rota protegida — assinando com a mesma signingKey declarada no scheme: jwt do seu YAML (veja Autenticação e autorização). Um pequeno console app usando System.IdentityModel.Tokens.Jwt é suficiente; veja samples/03-inventory-orders/tools/mint-token e samples/06-full-stack/tools/mint-token no repositório do Pipevine para exemplos completos e reutilizáveis.

Para onde ir daqui

Esse é o último capítulo do guia — a partir daqui:

• Referência de configuração YAML — todo campo do documento, para consulta.
• Extensibilidade — quando o vocabulário embutido não cobre o que sua aplicação precisa.
• Versionamento — o que você pode confiar que não muda.