DEV Community

Cover image for Automação de Testes de API com Robot Framework: Guia Prático
Lucas
Lucas

Posted on • Originally published at apidog.com

Automação de Testes de API com Robot Framework: Guia Prático

O Robot Framework adota uma abordagem diferente das ferramentas code-first: em vez de escrever testes como código de programa, você descreve cenários em tabelas de palavras-chave legíveis por humanos. Para testes de API, a RequestsLibrary transforma chamadas HTTP em palavras-chave como Create Session, GET On Session e Status Should Be, permitindo que QA, analistas e desenvolvedores revisem a mesma suíte.

Experimente o Apidog hoje

Este guia mostra como automatizar testes de API com Robot Framework de ponta a ponta: instalação, primeiro teste, sessões autenticadas, asserções em status e JSON, criação de palavras-chave reutilizáveis e execução em CI.

O que é o Robot Framework e por que ele funciona bem para testes de API

O Robot Framework é um framework open source de automação de testes e processos. Sua principal característica é a sintaxe orientada por palavras-chave: os testes são escritos em tabelas simples, e os comportamentos são fornecidos por bibliotecas implementadas em Python ou Java.

Para APIs, isso traz duas vantagens práticas:

  • Legibilidade: os testes parecem uma lista de passos verificáveis.
  • Extensibilidade: bibliotecas como robotframework-requests expõem operações HTTP como palavras-chave.

A RequestsLibrary envolve a biblioteca Python requests e permite escrever chamadas HTTP sem criar código Python para cada teste. Se a estrutura orientada por palavras-chave for nova para você, este guia sobre frameworks de teste de automação explica onde ela se encaixa.

Instalando o Robot Framework e as bibliotecas necessárias

Use um ambiente virtual para isolar dependências do projeto:

python -m venv .venv
source .venv/bin/activate

pip install robotframework
pip install robotframework-requests
pip install robotframework-jsonlibrary
Enter fullscreen mode Exit fullscreen mode

Esses pacotes cobrem a base de uma suíte de testes de API:

  • robotframework: motor principal e executor de testes.
  • robotframework-requests: biblioteca para chamadas HTTP.
  • robotframework-jsonlibrary: utilitários para extrair e validar valores em JSON.

Verifique a instalação:

robot --version
Enter fullscreen mode Exit fullscreen mode

A documentação oficial do Robot Framework User Guide é a referência principal para sintaxe e recursos avançados.

Atenção: o Robot Framework é sensível a espaços. Palavras-chave e argumentos devem ser separados por pelo menos dois espaços. Um único espaço pode ser interpretado como parte do mesmo token.

Escrevendo seu primeiro teste de API

Arquivos de teste usam a extensão .robot e normalmente são organizados em seções:

  • *** Settings ***
  • *** Variables ***
  • *** Test Cases ***
  • *** Keywords ***

Crie um arquivo chamado tests.robot:

*** Settings ***
Library           RequestsLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Test Cases ***
Get User Returns 200
    Create Session    api    ${BASE_URL}
    ${response}=      GET On Session    api    /users/42
    Status Should Be  200    ${response}

Get User Returns Expected Data
    Create Session    api    ${BASE_URL}
    ${response}=      GET On Session    api    /users/42
    ${body}=          Set Variable    ${response.json()}
    Should Be Equal As Integers    ${body}[id]    42
    Should Be Equal                ${body}[status]    active
Enter fullscreen mode Exit fullscreen mode

Execute:

robot tests.robot
Enter fullscreen mode Exit fullscreen mode

Ao final, o Robot Framework gera automaticamente:

  • output.xml
  • log.html
  • report.html

Os pontos principais do teste são:

  • Create Session: cria uma sessão HTTP nomeada.
  • GET On Session: envia uma requisição GET usando a sessão.
  • Status Should Be: valida o código HTTP.
  • Should Be Equal: compara valores do corpo da resposta.

Trabalhando com sessões HTTP

Create Session não armazena apenas a URL base. A sessão também pode manter cabeçalhos, autenticação e cookies. Isso é útil para APIs que exigem login antes das demais chamadas.

Exemplo com autenticação:

*** Settings ***
Library           RequestsLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Test Cases ***
Create Order With Authenticated Session
    Create Session    api    ${BASE_URL}

    ${login}=         POST On Session    api    /auth/login
    ...               json={"email": "qa@example.com", "password": "test-pass"}

    ${token}=         Set Variable    ${login.json()}[token]
    ${headers}=       Create Dictionary    Authorization=Bearer ${token}

    ${order}=         POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}
    ...               headers=${headers}

    Status Should Be  201    ${order}
Enter fullscreen mode Exit fullscreen mode

A sintaxe ... continua a chamada da palavra-chave na linha seguinte. Use-a para manter payloads, headers e parâmetros legíveis.

A referência completa das palavras-chave está na documentação da RequestsLibrary.

Validando corpos de resposta JSON

Validar apenas o status HTTP não é suficiente. Também verifique campos obrigatórios, tipos esperados e valores de negócio.

Exemplo:

*** Settings ***
Library           RequestsLibrary
Library           JSONLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Test Cases ***
Order Response Has Correct Shape
    Create Session    api    ${BASE_URL}

    ${response}=      POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}

    Status Should Be  201    ${response}

    ${body}=          Set Variable    ${response.json()}

    Dictionary Should Contain Key    ${body}    total
    Dictionary Should Contain Key    ${body}    status
    Should Be Equal As Integers      ${body}[quantity]    2

    ${status}=        Get Value From Json    ${body}    $.status
    Should Be Equal   ${status}[0]    pending
Enter fullscreen mode Exit fullscreen mode

Boas práticas para asserções em API:

  • Valide o status code.
  • Confirme campos obrigatórios com Dictionary Should Contain Key.
  • Compare números com Should Be Equal As Integers.
  • Use JSONPath com Get Value From Json para campos aninhados.
  • Evite validar somente a existência do corpo; valide conteúdo relevante.

Para uma lista mais ampla de verificações úteis, veja este guia sobre asserções de API.

Criando palavras-chave reutilizáveis

Repetir login e criação de sessão em cada teste torna a suíte difícil de manter. Use a seção *** Keywords *** para encapsular passos comuns.

*** Settings ***
Library           RequestsLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Keywords ***
Authenticate And Open Session
    Create Session    api    ${BASE_URL}

    ${login}=         POST On Session    api    /auth/login
    ...               json={"email": "qa@example.com", "password": "test-pass"}

    ${token}=         Set Variable    ${login.json()}[token]
    ${headers}=       Create Dictionary    Authorization=Bearer ${token}

    Set Suite Variable    ${AUTH_HEADERS}    ${headers}

*** Test Cases ***
Create Order
    Authenticate And Open Session

    ${order}=         POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}
    ...               headers=${AUTH_HEADERS}

    Status Should Be  201    ${order}
Enter fullscreen mode Exit fullscreen mode

Agora, se o fluxo de login mudar, você altera apenas a palavra-chave Authenticate And Open Session.

Para suítes maiores, mova palavras-chave compartilhadas para um arquivo de recurso.

Exemplo common.robot:

*** Settings ***
Library           RequestsLibrary
Library           Collections

*** Variables ***
${BASE_URL}       https://api.example.com/v1

*** Keywords ***
Authenticate And Open Session
    Create Session    api    ${BASE_URL}

    ${login}=         POST On Session    api    /auth/login
    ...               json={"email": "qa@example.com", "password": "test-pass"}

    ${token}=         Set Variable    ${login.json()}[token]
    ${headers}=       Create Dictionary    Authorization=Bearer ${token}

    Set Suite Variable    ${AUTH_HEADERS}    ${headers}
Enter fullscreen mode Exit fullscreen mode

Depois, importe no arquivo de teste:

*** Settings ***
Resource          common.robot

*** Test Cases ***
Create Order
    Authenticate And Open Session

    ${order}=         POST On Session    api    /orders
    ...               json={"product_id": 7, "quantity": 2}
    ...               headers=${AUTH_HEADERS}

    Status Should Be  201    ${order}
Enter fullscreen mode Exit fullscreen mode

Esse padrão ajuda a separar:

  • casos de teste;
  • configuração global;
  • autenticação;
  • utilitários de API;
  • validações reutilizáveis.

A mesma disciplina modular é discutida neste guia sobre como escrever scripts de teste automatizados.

Organizando uma suíte de testes de API

Uma estrutura simples para começar:

api-tests/
├── requirements.txt
├── tests/
│   ├── users.robot
│   ├── orders.robot
│   └── health.robot
└── resources/
    ├── common.robot
    ├── auth.robot
    └── assertions.robot
Enter fullscreen mode Exit fullscreen mode

Exemplo de requirements.txt:

robotframework
robotframework-requests
robotframework-jsonlibrary
Enter fullscreen mode Exit fullscreen mode

Exemplo de importação em um teste:

*** Settings ***
Resource          ../resources/common.robot
Resource          ../resources/auth.robot
Resource          ../resources/assertions.robot
Enter fullscreen mode Exit fullscreen mode

Uma boa regra: deixe os arquivos em tests/ descreverem o comportamento esperado da API, e coloque detalhes repetitivos em resources/.

Essa separação é o núcleo da abordagem orientada por palavras-chave. Para entender por que isso escala, veja também o guia sobre frameworks de teste de automação.

Executando o Robot Framework em CI

O Robot Framework funciona bem em pipelines porque:

  • roda em modo headless;
  • retorna código de saída diferente de zero quando há falhas;
  • gera relatórios HTML automaticamente;
  • aceita variáveis por linha de comando.

Exemplo local ou em CI:

robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/
Enter fullscreen mode Exit fullscreen mode

Flags úteis:

  • --outputdir results: envia relatórios para uma pasta conhecida.
  • --variable BASE_URL:...: injeta variáveis de ambiente.
  • --include smoke: executa apenas testes com uma tag.
  • --exclude slow: ignora testes marcados como lentos.

Adicione tags aos testes:

*** Test Cases ***
Health Check
    [Tags]    smoke
    Create Session    api    ${BASE_URL}
    ${response}=      GET On Session    api    /health
    Status Should Be  200    ${response}
Enter fullscreen mode Exit fullscreen mode

Executar apenas smoke tests:

robot --include smoke --outputdir results tests/
Enter fullscreen mode Exit fullscreen mode

Um pipeline típico segue estes passos:

  1. Fazer checkout do repositório.
  2. Instalar Python.
  3. Instalar dependências.
  4. Executar robot.
  5. Publicar log.html e report.html como artefatos.

Esse fluxo é o mesmo usado em estratégias de testes de API em CI/CD.

Quando uma plataforma de API dedicada ajuda mais

O Robot Framework é uma boa escolha quando você precisa de testes legíveis, orientados por palavras-chave, e mantidos por equipes com perfis variados.

Ele pode ser menos conveniente quando o fluxo também exige:

  • design de API;
  • mocking;
  • depuração visual;
  • validação automática contra OpenAPI;
  • gerenciamento centralizado de ambientes;
  • execução de testes sem criar bibliotecas de palavras-chave.

O Apidog cobre essas necessidades em uma plataforma dedicada para APIs. Ele oferece construtor visual de testes, validação automática de esquema OpenAPI, execuções orientadas por dados em CSV e JSON, gerenciamento de ambientes, relatórios HTML e executor CLI para CI.

Na prática, equipes podem usar ambos:

  • Robot Framework para suítes orientadas por palavras-chave e altamente legíveis.
  • Apidog para projetar, simular, depurar e testar APIs de forma mais integrada.

Você pode baixar o Apidog e configurar uma suíte funcional de testes de API sem escrever bibliotecas de palavras-chave.

Perguntas frequentes

O Robot Framework é apenas para testes de UI?

Não. O Robot Framework é um framework genérico de automação. Com a RequestsLibrary, ele funciona bem para testes de API. Outras bibliotecas cobrem bancos de dados, SSH e outros tipos de automação. Ele ficou popular em UI por causa da SeleniumLibrary, mas testes de API também são um uso comum.

Qual é a diferença entre Create Session e uma requisição simples?

Create Session cria uma sessão HTTP nomeada e persistente. Ela pode armazenar URL base, cabeçalhos, cookies e autenticação. Palavras-chave como GET On Session e POST On Session reutilizam esse estado.

Uma requisição sem sessão não preserva cookies ou autenticação entre chamadas, então você teria que reenviar esses dados manualmente em cada requisição.

Preciso saber Python para usar o Robot Framework?

Não para escrever testes. A sintaxe baseada em palavras-chave foi criada para ser legível por pessoas que não necessariamente programam. A RequestsLibrary já expõe operações HTTP como palavras-chave.

Python se torna útil quando você precisa criar bibliotecas de palavras-chave novas. Para muitos cenários de API, as bibliotecas existentes são suficientes.

Como o Robot Framework se compara ao pytest para testes de API?

O pytest é code-first e combina bem com equipes Python que querem escrever testes próximos ao código da aplicação.

O Robot Framework é orientado por palavras-chave e funciona melhor quando a legibilidade em formato de tabela é importante para QA, analistas, produto e desenvolvimento.

Ambos podem rodar em CI e gerar relatórios. A escolha depende mais de quem vai manter a suíte do que da capacidade técnica básica.

O Robot Framework pode validar respostas contra um esquema OpenAPI?

Não nativamente. Você pode validar campos individuais com palavras-chave embutidas e JSONLibrary, e também pode usar bibliotecas da comunidade para validação de esquema.

Se a validação automática contra um documento OpenAPI for parte central do fluxo, uma plataforma como o Apidog pode reduzir o trabalho de montar e manter essa camada manualmente.

Top comments (0)