Para executar testes de API do Apidog CLI no CircleCI, crie .circleci/config.yml, use um executor Docker cimg/node, instale apidog-cli com npm e rode apidog run com token de acesso, ID do cenário de teste e ID do ambiente. Guarde esses valores como variáveis de ambiente no CircleCI e publique relatórios JUnit/HTML com store_test_results e store_artifacts.
Este guia foca na execução dos testes no CircleCI. Se você ainda está escolhendo uma ferramenta de CI, veja a comparação entre CircleCI e Jenkins. Aqui, assumimos que o CircleCI já está conectado ao seu repositório e que você quer rodar sua suíte de API a cada push.
O que você vai configurar
O pipeline terá um job chamado api-tests que:
- Faz checkout do repositório.
- Instala o Apidog CLI.
- Executa um cenário de teste do Apidog.
- Gera relatórios no terminal, JUnit e HTML.
- Publica os resultados no CircleCI.
A configuração fica em:
.circleci/config.yml
O CircleCI lê esse arquivo a cada push e executa os jobs definidos nele.
Conceitos básicos do CircleCI
Uma configuração do CircleCI usa três blocos principais:
- Jobs: unidades de trabalho, como instalar dependências e executar testes.
-
Executores: ambientes onde os jobs rodam. Neste guia, usamos Docker com
cimg/node. - Workflows: definem quais jobs rodam e em qual ordem.
Para testes de API, a ideia é simples: criar um job que executa apidog run e um workflow que chama esse job.
Por que rodar testes de API no CircleCI
Rodar testes de API em CI ajuda a detectar problemas antes do deploy, como:
- mudanças inesperadas no contrato da API;
- campos removidos ou renomeados;
- falhas em autenticação;
- respostas com status code incorreto;
- regressões em fluxos críticos.
O Apidog CLI permite executar no CI os mesmos cenários criados no Apidog, sem precisar reescrever asserções em um framework separado.
Se quiser aprofundar a estratégia de testes em pipelines, veja também as 12 melhores práticas de CI/CD para testes de API.
Pré-requisitos
Antes de configurar o CircleCI, tenha estes dados no Apidog:
- Token de acesso: usado pelo CLI para autenticar a execução. Veja o guia de autenticação do Apidog CLI.
- ID do cenário de teste: identifica qual cenário será executado.
- ID do ambiente: define a URL base e as variáveis usadas na execução, como staging ou produção.
Você também precisa de:
- uma conta CircleCI;
- o projeto habilitado no painel do CircleCI;
- um repositório Git com permissão para criar
.circleci/config.yml.
Configure variáveis de ambiente no CircleCI
Não coloque tokens diretamente no config.yml. Esse arquivo fica versionado no Git.
No CircleCI, crie as seguintes variáveis:
APIDOG_ACCESS_TOKEN
APIDOG_TEST_SCENARIO_ID
APIDOG_ENVIRONMENT_ID
Você pode adicioná-las de duas formas:
Opção 1: variáveis do projeto
Use quando o token será usado apenas por um repositório.
No CircleCI:
- Abra o projeto.
- Vá em Project Settings.
- Acesse Environment Variables.
- Adicione as três variáveis.
Opção 2: contextos
Use quando vários repositórios compartilham os mesmos segredos.
No CircleCI:
- Vá em Organization Settings.
- Abra Contexts.
- Crie um contexto, por exemplo
apidog-secrets. - Adicione as variáveis ao contexto.
- Referencie o contexto no workflow.
Configuração completa do .circleci/config.yml
Crie o arquivo abaixo em .circleci/config.yml:
version: 2.1
jobs:
api-tests:
docker:
- image: cimg/node:20.11
steps:
- checkout
- run:
name: Install Apidog CLI
command: npm install -g apidog-cli
- run:
name: Run Apidog API tests
command: |
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t $APIDOG_TEST_SCENARIO_ID \
-e $APIDOG_ENVIRONMENT_ID \
-r cli,junit,html \
--out-dir ./reports
- store_test_results:
path: ./reports
- store_artifacts:
path: ./reports
workflows:
test-api:
jobs:
- api-tests
Depois:
git add .circleci/config.yml
git commit -m "Add Apidog API tests to CircleCI"
git push
O CircleCI deve iniciar o pipeline automaticamente.
Entendendo o executor
docker:
- image: cimg/node:20.11
cimg/node é uma imagem Docker mantida pelo CircleCI para projetos Node.js. Ela já inclui Node.js, npm e ferramentas comuns de build.
A tag 20.11 fixa a versão do Node. Se sua equipe usa outra versão, ajuste a tag:
docker:
- image: cimg/node:18.19
Entendendo as etapas do job
Checkout do código
- checkout
Baixa o repositório para o ambiente do job.
Instalação do Apidog CLI
- run:
name: Install Apidog CLI
command: npm install -g apidog-cli
Instala o CLI globalmente no contêiner.
Execução dos testes
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t $APIDOG_TEST_SCENARIO_ID \
-e $APIDOG_ENVIRONMENT_ID \
-r cli,junit,html \
--out-dir ./reports
Flags usadas:
-
--access-token: autentica o CLI. -
-t: define o ID do cenário de teste. -
-e: define o ID do ambiente. -
-r: define os reporters. -
--out-dir: define onde os relatórios serão gravados.
Neste exemplo, usamos três reporters:
cli,junit,html
Eles geram:
- saída no log do CircleCI;
- relatório JUnit para a aba de testes;
- relatório HTML para download como artifact.
Publicando relatórios no CircleCI
- store_test_results:
path: ./reports
- store_artifacts:
path: ./reports
store_test_results envia os arquivos JUnit para o CircleCI. Assim, o build mostra uma aba de testes com falhas, nomes dos casos e duração.
store_artifacts publica os arquivos gerados em ./reports, incluindo o relatório HTML.
Para entender melhor os formatos de saída, consulte o guia de relatórios de teste do Apidog CLI.
Rodar testes apenas em branches específicas
Se você não quiser executar a suíte de API em todas as branches, adicione filtros no workflow:
workflows:
test-api:
jobs:
- api-tests:
filters:
branches:
only:
- main
- develop
Com isso, o job api-tests roda apenas em pushes para main e develop.
Usar um contexto do CircleCI
Se você criou um contexto chamado apidog-secrets, referencie-o assim:
workflows:
test-api:
jobs:
- api-tests:
context:
- apidog-secrets
O job passa a acessar as variáveis definidas no contexto, como:
APIDOG_ACCESS_TOKEN
APIDOG_TEST_SCENARIO_ID
APIDOG_ENVIRONMENT_ID
Isso facilita rotação de tokens e compartilhamento entre projetos.
Execuções orientadas a dados
Para rodar o mesmo cenário com múltiplos dados de entrada, use -d:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t $APIDOG_TEST_SCENARIO_ID \
-e $APIDOG_ENVIRONMENT_ID \
-d ./data/users.csv \
-r cli,junit \
--out-dir ./reports
A flag -d aceita um arquivo CSV ou JSON, ou um ID numérico de conjunto de dados armazenado.
Exemplo com CSV:
email,password
user1@example.com,secret123
user2@example.com,secret456
Veja mais no guia de testes orientados a dados.
Controlar comportamento em falhas
Você pode ajustar o comportamento da execução com --on-error.
Exemplo:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t $APIDOG_TEST_SCENARIO_ID \
-e $APIDOG_ENVIRONMENT_ID \
--on-error end \
-r cli,junit,html \
--out-dir ./reports
Valores aceitos:
-
continue: continua mesmo após erro. -
end: encerra ao encontrar erro. -
ignore: ignora erros na execução.
Use end quando quiser falhar rápido em fluxos críticos.
Executar testes de uma branch do Apidog
Se seu projeto usa branches no Apidog, informe o projeto e a branch:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
--project $APIDOG_PROJECT_ID \
--branch feature-auth \
-t $APIDOG_TEST_SCENARIO_ID \
-e $APIDOG_ENVIRONMENT_ID \
-r cli,junit,html \
--out-dir ./reports
Nesse caso, adicione também a variável:
APIDOG_PROJECT_ID
Enviar relatório para a nuvem do Apidog
Para enviar uma visão geral do relatório para o Apidog, adicione:
--upload-report
Exemplo:
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t $APIDOG_TEST_SCENARIO_ID \
-e $APIDOG_ENVIRONMENT_ID \
-r cli,junit,html \
--out-dir ./reports \
--upload-report
Como isso se encaixa no fluxo do Apidog
O fluxo recomendado é:
- Criar ou editar o cenário no Apidog.
- Definir asserções de status code, headers e corpo da resposta.
- Salvar o cenário.
- Rodar o mesmo cenário no CircleCI com
apidog run.
Você pode criar um cenário de teste a partir da linha de comando ou usar o construtor visual do Apidog.
A configuração de CI fica estável. Quando alguém altera asserções no Apidog, o próximo build do CircleCI executa a versão atualizada do cenário.
A divisão fica clara:
- Apidog define o que testar.
- CircleCI define quando e onde executar.
Se quiser comparar alternativas de CI para equipes de API, veja o resumo de ferramentas de integração contínua para equipes de API.
Checklist de implementação
Antes de finalizar, confirme:
- [ ]
.circleci/config.ymlexiste na raiz do repositório. - [ ]
APIDOG_ACCESS_TOKENestá configurado no CircleCI. - [ ]
APIDOG_TEST_SCENARIO_IDestá configurado. - [ ]
APIDOG_ENVIRONMENT_IDestá configurado. - [ ] O comando
apidog runusa-r cli,junit,html. - [ ]
store_test_resultsaponta para./reports. - [ ]
store_artifactsaponta para./reports. - [ ] O pipeline roda ao fazer push.
Pronto para colocar sua suíte de API em cada push? Baixe o Apidog, crie um cenário de teste e adicione a configuração acima ao seu repositório.
Perguntas Frequentes
O que é CircleCI?
CircleCI é uma plataforma de integração e entrega contínua em nuvem. Ela se conecta ao seu repositório Git, lê .circleci/config.yml e executa automaticamente etapas de build, teste e deploy a cada push.
Para que é usado o CircleCI?
Equipes usam CircleCI para automatizar tarefas como:
- compilar código;
- executar testes unitários;
- executar testes de integração;
- validar contratos de API;
- construir imagens Docker;
- publicar releases em staging ou produção.
Neste guia, o CircleCI executa testes de API do Apidog CLI.
O CircleCI é gratuito?
O CircleCI possui um plano gratuito com uma alocação mensal de créditos de build, útil para pequenos projetos e repositórios pessoais. Equipes que precisam de mais concorrência, minutos ou máquinas maiores podem usar planos pagos. Consulte a página de preços atual do CircleCI para limites exatos.
O CircleCI é de código aberto?
Não. CircleCI é um produto comercial hospedado. Você o configura com YAML e pode executá-lo na infraestrutura do CircleCI ou em runners auto-hospedados.
Se você precisa de um servidor CI totalmente open source, Jenkins é uma alternativa comum. A comparação CircleCI vs Jenkins aborda esse cenário.
Como funciona o CircleCI?
Quando você faz um commit, o CircleCI detecta a mudança, lê .circleci/config.yml e inicia o executor definido, como um contêiner Docker cimg/node.
Depois, ele executa as etapas dos jobs em ordem e envia o resultado para o provedor Git. Workflows permitem encadear e paralelizar jobs.
Para uma visão mais ampla de pipelines de entrega, consulte o guia O que é CI/CD.
Top comments (0)