DEV Community

Cover image for Automatización de Pruebas API con Robot Framework: Guía Práctica
Roobia
Roobia

Posted on • Originally published at apidog.com

Automatización de Pruebas API con Robot Framework: Guía Práctica

Robot Framework adopta una postura diferente a las herramientas que priorizan el código: en lugar de escribir pruebas como código de programa, defines casos como tablas de palabras clave legibles. Para pruebas de API, RequestsLibrary convierte llamadas HTTP en pasos como Create Session, GET On Session y Status Should Be, lo que permite que QA, analistas y developers revisen la misma suite.

Prueba Apidog hoy

En esta guía vas a montar una suite de pruebas de API con Robot Framework desde cero: instalación, primera prueba, sesiones autenticadas, aserciones sobre JSON, palabras clave reutilizables y ejecución en CI.

Qué es Robot Framework y por qué encaja en pruebas de API

Robot Framework es un framework de automatización genérico y open source para pruebas y automatización de procesos. Su característica principal es la sintaxis basada en palabras clave: las pruebas se escriben en tablas simples y el comportamiento complejo se delega a librerías implementadas en Python o Java.

Para pruebas de API aporta dos ventajas prácticas:

  • Las pruebas son legibles para perfiles no necesariamente centrados en código.
  • Es extensible: RequestsLibrary envuelve requests de Python y expone operaciones HTTP como palabras clave.

Si la estructura basada en palabras clave es nueva para ti, esta guía sobre frameworks de pruebas de automatización explica dónde encaja Robot Framework frente a otros enfoques.

Instalación de Robot Framework y librerías necesarias

Crea un entorno virtual e instala los paquetes básicos:

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

Estos paquetes cubren la mayoría de escenarios de testing de API:

  • robotframework: motor principal y runner de pruebas.
  • robotframework-requests: RequestsLibrary para enviar solicitudes HTTP.
  • robotframework-jsonlibrary: utilidades para extraer y verificar valores JSON.

Verifica la instalación:

robot --version
Enter fullscreen mode Exit fullscreen mode

La guía oficial de Robot Framework es la referencia principal para sintaxis y configuración avanzada.

Importante: Robot Framework es sensible a los espacios. Las palabras clave y sus argumentos deben separarse con al menos dos espacios. Un solo espacio se interpreta como parte del mismo token.

Estructura básica de un archivo .robot

Un archivo de prueba usa la extensión .robot y normalmente se divide en estas secciones:

*** 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}
Enter fullscreen mode Exit fullscreen mode

Qué hace cada parte:

  • *** Settings ***: importa librerías.
  • *** Variables ***: define valores reutilizables.
  • *** Test Cases ***: contiene los casos de prueba.
  • Create Session: crea una sesión HTTP con nombre.
  • GET On Session: ejecuta una solicitud GET.
  • Status Should Be: valida el código de estado.

Ejecuta la suite:

robot tests.robot
Enter fullscreen mode Exit fullscreen mode

Robot Framework generará automáticamente:

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

Primera prueba de API con validación de JSON

Este ejemplo valida que un endpoint de usuario responda 200 y devuelva los datos esperados:

*** Settings ***
Library           RequestsLibrary
Library           Collections

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

*** Test Cases ***
Get User Returns Expected Data
    Create Session    api    ${BASE_URL}
    ${response}=      GET On Session    api    /users/42

    Status Should Be  200    ${response}

    ${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

Puntos clave:

  • ${response.json()} convierte el cuerpo en un objeto accesible desde Robot Framework.
  • Should Be Equal As Integers evita problemas de comparación entre strings y números.
  • Should Be Equal valida valores exactos.

Trabajando con sesiones HTTP

Create Session no solo guarda una URL base. También puede mantener encabezados, cookies y autenticación. Esto es útil cuando una API requiere login antes de ejecutar otros endpoints.

Ejemplo con autenticación:

*** 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

La sintaxis ... continúa una palabra clave en la siguiente línea. Úsala para mantener legibles solicitudes con payloads, headers o parámetros largos.

Las palabras clave disponibles están documentadas en la referencia de RequestsLibrary.

Aserciones sobre cuerpos de respuesta

Validar solo el status code no suele ser suficiente. También conviene comprobar estructura, campos obligatorios y valores esperados.

*** 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
    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

Estas palabras clave cubren validaciones comunes:

  • Dictionary Should Contain Key: confirma que un campo existe.
  • Should Be Equal As Integers: compara valores numéricos.
  • Get Value From Json: extrae valores usando JSONPath.

Para ampliar el set de verificaciones, esta guía sobre aserciones de API complementa bien este flujo.

Crear palabras clave reutilizables

Si repites login, headers o creación de sesión en cada prueba, mueve esos pasos a palabras clave propias.

*** 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]
    Set Suite Variable    ${AUTH_HEADERS}    Bearer ${token}

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

    ${headers}=       Create Dictionary    Authorization=${AUTH_HEADERS}

    ${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

Ventaja práctica: si cambia el endpoint de login, solo modificas una palabra clave.

Usar archivos de recursos

Para suites grandes, separa las palabras clave compartidas en archivos de recursos.

Ejemplo de 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]
    Set Suite Variable    ${AUTH_HEADERS}    Bearer ${token}
Enter fullscreen mode Exit fullscreen mode

Luego impórtalo desde tu archivo de pruebas:

*** Settings ***
Resource          common.robot

*** Test Cases ***
Create Order
    Authenticate And Open Session
Enter fullscreen mode Exit fullscreen mode

Una estructura típica puede ser:

tests/
  users.robot
  orders.robot
resources/
  common.robot
  auth.robot
  users_keywords.robot
  orders_keywords.robot
Enter fullscreen mode Exit fullscreen mode

Esta separación mantiene los casos de prueba enfocados en intención y deja la lógica repetible en recursos compartidos. Es la misma disciplina modular descrita en la guía sobre cómo escribir scripts de pruebas automatizados.

También puedes revisar la guía de frameworks de pruebas de automatización para entender por qué esta estructura escala mejor que copiar y pegar pasos.

Ejecutar Robot Framework en CI

Robot Framework funciona bien en CI porque:

  • Se ejecuta sin interfaz gráfica.
  • Devuelve código de salida distinto de cero cuando hay fallos.
  • Genera reportes HTML automáticamente.

Ejemplo básico:

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

Para inyectar variables de entorno, usa --variable:

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

También puedes usar tags para ejecutar subconjuntos:

*** 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

Ejecutar solo smoke tests:

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

Patrón típico para CI:

  1. Instalar Python.
  2. Instalar dependencias con pip.
  3. Ejecutar robot.
  4. Publicar results/log.html y results/report.html como artefactos.

Este flujo sigue el mismo enfoque descrito en la guía de pruebas de API en CI/CD.

Cuándo una plataforma de API dedicada ayuda más

Robot Framework es una buena opción cuando quieres pruebas legibles, basadas en palabras clave y mantenibles por equipos con distintos perfiles técnicos.

Puede ser menos cómodo si también necesitas en un solo lugar:

  • Diseño de API.
  • Mocking.
  • Depuración de solicitudes.
  • Validación de esquemas OpenAPI.
  • Ejecución basada en datos sin ensamblar librerías adicionales.

Apidog cubre esas necesidades directamente. Proporciona constructor visual de pruebas, validación automática de esquemas OpenAPI, ejecuciones basadas en datos desde CSV y JSON, gestión de entornos, informes HTML y un ejecutor CLI para CI.

Un enfoque común es usar ambos:

  • Robot Framework para suites legibles basadas en palabras clave.
  • Apidog para diseñar, simular, depurar y probar APIs de forma más integrada.

Puedes descargar Apidog y configurar una suite de pruebas de API sin escribir librerías de palabras clave.

Preguntas frecuentes

¿Robot Framework es solo para pruebas de interfaz de usuario?

No. Robot Framework es un framework de automatización genérico. Con RequestsLibrary puede ejecutar pruebas de API, y existen librerías para bases de datos, SSH y otros sistemas. SeleniumLibrary lo hizo popular en pruebas de UI, pero las pruebas de API son un caso de uso habitual.

¿Cuál es la diferencia entre Create Session y una solicitud simple?

Create Session crea una sesión HTTP persistente con nombre. Esa sesión puede guardar URL base, headers, cookies y autenticación. Luego, palabras clave como GET On Session o POST On Session reutilizan ese estado.

Una solicitud sin sesión no mantiene cookies ni autenticación entre llamadas, por lo que tendrías que reenviar esa información cada vez.

¿Necesito saber Python para usar Robot Framework?

No para escribir pruebas. La sintaxis basada en tablas está diseñada para que puedas usar palabras clave existentes sin escribir Python.

Python solo es necesario si quieres crear librerías de palabras clave nuevas. Para muchas suites de API, RequestsLibrary, JSONLibrary y las palabras clave incorporadas son suficientes.

¿Cómo se compara Robot Framework con pytest para pruebas de API?

Pytest prioriza código Python y encaja bien cuando developers quieren mantener las pruebas junto al código de la aplicación.

Robot Framework prioriza legibilidad y palabras clave, por lo que suele encajar mejor en equipos mixtos donde QA, analistas y developers revisan la misma suite.

Ambos pueden ejecutarse en CI y generar reportes. La elección depende más de quién mantendrá las pruebas que de la capacidad técnica base.

¿Puede Robot Framework validar respuestas contra un esquema OpenAPI?

No de forma predeterminada. Puedes validar campos individuales con palabras clave incorporadas y JSONLibrary, y también existen librerías de comunidad para validación de esquemas.

Si la validación automática contra OpenAPI es una parte central del flujo, una plataforma como Apidog puede reducir el trabajo de integración y mantenimiento.

Top comments (0)