DEV Community: Roobia

Cómo Usar Insomnia para Probar una API

Roobia — Fri, 22 May 2026 07:32:10 +0000

Insomnia es un cliente API de Kong para enviar solicitudes e inspeccionar respuestas. Soporta HTTP, REST, GraphQL, gRPC, SOAP y WebSocket desde una interfaz limpia. Es útil cuando necesita probar APIs sin usar una herramienta pesada tipo IDE, pero con suficientes funciones para depurar, parametrizar y automatizar verificaciones.

Prueba Apidog hoy

En esta guía probará una API en Insomnia de principio a fin: creará una colección, enviará una solicitud, inspeccionará la respuesta, configurará entornos para cambiar URLs base y tokens, y escribirá aserciones con suites de pruebas. Los ejemplos usan JSONPlaceholder para que pueda seguirlos sin configurar backend propio.

Instalar Insomnia y crear una solicitud

Descargue Insomnia desde el sitio oficial de Kong e instálelo en su plataforma.

Al abrirlo por primera vez, Insomnia le preguntará si desea iniciar sesión. Puede trabajar localmente sin cuenta si no necesita sincronización en la nube. Insomnia almacenará sus datos en su máquina.

Para crear su primera solicitud:

Abra Insomnia.
Haga clic en Crear.
Seleccione Colección de solicitudes.
Asigne un nombre, por ejemplo: Pruebas de la API de usuario.
Dentro de la colección, haga clic en +.
Elija Solicitud HTTP.
Configure el método como GET.
Introduzca esta URL:

GET https://jsonplaceholder.typicode.com/users/1

Haga clic en Enviar.

Insomnia mostrará:

Código de estado HTTP.
Tiempo de respuesta.
Tamaño de la respuesta.
Cuerpo de respuesta formateado.
Encabezados recibidos.

Para respuestas JSON grandes, use el filtro JSONPath en el panel de respuesta. Por ejemplo, si desea inspeccionar solo el email:

$.email

Configurar métodos, parámetros y autenticación

Una solicitud real suele necesitar cuerpo, parámetros, encabezados o autenticación. Insomnia agrupa estas opciones en pestañas debajo de la barra de URL.

Enviar un cuerpo JSON

Para probar un endpoint POST:

Cambie el método a POST.
Abra la pestaña Cuerpo.
Seleccione JSON.
Escriba el payload:

{
  "name": "Daniel Okafor",
  "email": "daniel.okafor@example.com"
}

Cuando selecciona JSON, Insomnia configura automáticamente el encabezado:

Content-Type: application/json

Añadir parámetros de consulta

Use la pestaña Consulta para añadir query params sin editar manualmente la URL.

Por ejemplo, en lugar de escribir:

GET https://jsonplaceholder.typicode.com/posts?userId=1

Configure:

Nombre	Valor
`userId`	`1`

Esto facilita activar, desactivar o modificar parámetros durante las pruebas.

Añadir encabezados

Use la pestaña Encabezados para valores como:

Accept: application/json
X-Request-Id: test-123

Esto es útil para probar negociación de contenido, trazabilidad o comportamiento condicionado por headers.

Configurar autenticación

Abra la pestaña Auth y seleccione el esquema que usa su API. Insomnia soporta, entre otros:

Bearer Token.
Basic Auth.
API Key.
OAuth 1.0.
OAuth 2.0.
AWS IAM.

Para una API protegida por token:

Abra Auth.
Seleccione Bearer Token.
Pegue el token o use una variable de entorno.

Mejor que escribir el token directamente, use una variable:

{{ _.auth_token }}

Así evita duplicar credenciales en cada solicitud.

Si necesita validar qué códigos de estado debería devolver su API, consulte esta referencia sobre códigos de estado HTTP que las API REST deberían usar.

Configurar entornos y variables

Los entornos evitan repetir valores como URLs base, tokens o IDs de prueba. En Insomnia, un entorno es un objeto JSON asociado a una colección.

Para crear uno:

Abra el desplegable de entorno en la parte superior de la barra lateral.
Seleccione Administrar entornos.
Edite el Entorno Base o cree subentornos.
Añada variables en formato JSON.

Ejemplo:

{
  "base_url": "https://jsonplaceholder.typicode.com",
  "auth_token": "your-token-here"
}

Ahora puede reemplazar una URL fija como esta:

GET https://jsonplaceholder.typicode.com/users/1

Por una URL parametrizada:

GET {{ _.base_url }}/users/1

Cuando cambie el entorno activo, todas las solicitudes que usen {{ _.base_url }} apuntarán al nuevo destino.

Un patrón común es crear entornos como:

{
  "base_url": "https://api.dev.example.com",
  "auth_token": "dev-token"
}

{
  "base_url": "https://api.staging.example.com",
  "auth_token": "staging-token"
}

{
  "base_url": "https://api.example.com",
  "auth_token": "prod-token"
}

Encadenar solicitudes con etiquetas de plantilla

Insomnia también soporta etiquetas de plantilla. Son funciones que puede insertar en campos de solicitud para generar o extraer valores dinámicos.

Puede usarlas para:

Generar timestamps.
Crear UUIDs.
Reutilizar valores de entorno.
Extraer datos desde una respuesta anterior.
Encadenar login + solicitudes protegidas.

Ejemplo de flujo:

Cree una solicitud POST /login.
La respuesta devuelve un token:

{
  "token": "abc123"
}

En otra solicitud protegida, configure el encabezado:

Authorization: Bearer <token extraído de /login>

Con la etiqueta de respuesta, Insomnia puede ejecutar la solicitud de login si es necesario, leer el valor con JSONPath como:

$.token

Y reutilizarlo en las solicitudes siguientes.

Este enfoque mantiene el flujo declarativo y evita escribir scripts de unión solo para pasar datos entre requests.

Para organizar verificaciones relacionadas, revise este ejemplo de caso de prueba de API.

Escribir suites de pruebas con aserciones

Enviar una solicitud manualmente sirve para depurar. Para verificar automáticamente que una API sigue funcionando, use las suites de pruebas de Insomnia. En algunas versiones aparecen como Pruebas Unitarias dentro de una colección.

Para crear una suite:

Abra su colección.
Cambie a la vista Pruebas.
Cree una suite de pruebas.
Añada una prueba.
Seleccione la solicitud que debe ejecutarse.
Escriba las aserciones en JavaScript.

Insomnia usa Chai para las aserciones y expone insomnia.send() para ejecutar la solicitud asociada.

Ejemplo mínimo:

const response = await insomnia.send();

expect(response.status).to.equal(200);

Ejemplo con validación del cuerpo:

const response = await insomnia.send();
const body = JSON.parse(response.data);

expect(response.status).to.equal(200);
expect(body).to.have.property("id");
expect(body.email).to.equal("Sincere@april.biz");

Para la solicitud:

GET https://jsonplaceholder.typicode.com/users/1

La respuesta incluye un email como:

{
  "id": 1,
  "name": "Leanne Graham",
  "email": "Sincere@april.biz"
}

Por eso la aserción anterior valida tanto el estado como un campo específico del payload.

También puede validar encabezados:

const response = await insomnia.send();

expect(response.status).to.equal(200);
expect(response.headers["content-type"]).to.include("application/json");

Organizar suites de pruebas

A medida que crece la colección, no conviene tener todas las pruebas mezcladas. Use una estructura por recurso o dominio funcional.

Ejemplo:

Suites
├── Users
│   ├── GET /users/:id devuelve 200
│   ├── GET /users/:id devuelve estructura esperada
│   └── GET /users/:id inexistente devuelve 404
├── Posts
│   ├── GET /posts devuelve lista
│   └── POST /posts valida payload requerido
└── Auth
    ├── POST /login devuelve token
    └── POST /login con credenciales inválidas devuelve 401

Mantenga cada prueba enfocada en un comportamiento. Evite pruebas demasiado amplias como “la API funciona”, porque cuando fallen no sabrá qué se rompió.

Buen patrón:

const response = await insomnia.send();

expect(response.status).to.equal(404);

Mejor aún, si el endpoint devuelve un cuerpo de error estable:

const response = await insomnia.send();
const body = JSON.parse(response.data);

expect(response.status).to.equal(404);
expect(body).to.have.property("message");

Para profundizar en qué conviene validar, consulte la guía sobre aserciones de API. Para estructurar suites más grandes, revise el artículo sobre suites de pruebas para la automatización de pruebas de API.

Ejecutar pruebas desde la línea de comandos con Inso

La interfaz gráfica es útil durante el desarrollo, pero CI/CD necesita ejecución sin GUI. Insomnia incluye una herramienta de línea de comandos llamada Inso.

Después de exportar o sincronizar su colección, puede ejecutar una suite desde la terminal:

inso run test "User API tests"

Si alguna prueba falla, Inso devuelve un código de salida distinto de cero. Esto permite que una pipeline marque el build como fallido.

Ejemplo conceptual para CI:

inso run test "User API tests"
if [ $? -ne 0 ]; then
  echo "API tests failed"
  exit 1
fi

En una pipeline, el flujo típico sería:

Instalar Inso.
Obtener la colección o proyecto.
Seleccionar el entorno correcto.
Ejecutar la suite.
Fallar la compilación si alguna aserción falla.

Inso también puede lintar especificaciones de API y generar reportes de prueba en formatos estándar, por lo que no se limita a ejecutar suites.

Para el patrón general de automatización, consulte esta guía sobre automatización de pruebas de API en CI/CD.

El cambio a la nube en Insomnia 8 y una alternativa

Insomnia 8 se movió hacia un modelo cloud-first. Por defecto, impulsaba a los usuarios a crear una cuenta de Kong y almacenar proyectos en la nube.

Esto frustró a parte de la comunidad, porque versiones anteriores permitían un flujo completamente local y cómodo para trabajo sin conexión. Versiones posteriores restauraron una opción local más clara, como Scratch Pad, pero el cambio hizo que algunos equipos evaluaran alternativas, especialmente en entornos donde los datos no pueden salir de la organización.

Si ese es su caso, Apidog es una opción a considerar. Es una plataforma API todo en uno para diseño, depuración, mocking, pruebas y documentación. También permite importar exportaciones de Insomnia para no empezar desde cero.

Apidog permite construir aserciones visualmente sin escribir JavaScript, pero sigue admitiendo scripts cuando los necesita. Al mantener la especificación de API, los datos de prueba y el servidor mock en un mismo proyecto, las pruebas pueden mantenerse alineadas con el contrato real de la API.

Puede descargar Apidog e importar una colección de Insomnia para compararlos lado a lado. Para revisar más opciones, esta lista de herramientas de prueba de API en línea gratuitas cubre varias alternativas.

Insomnia sigue siendo un cliente potente y enfocado, especialmente para desarrolladores individuales y equipos pequeños que valoran una interfaz mínima y un inicio rápido. La mejor elección depende de cómo trabaja su equipo y de cuánto del ciclo de vida de la API quiere centralizar en una sola herramienta.

Preguntas frecuentes

¿Es Insomnia gratuito?

Insomnia tiene un nivel gratuito para uso individual, incluyendo envío de solicitudes y ejecución local de suites de pruebas. Los planes de pago añaden colaboración en equipo y mayores límites de sincronización en la nube. También puede trabajar localmente si no desea usar sincronización.

¿Qué protocolos soporta Insomnia?

Insomnia soporta HTTP, REST, GraphQL, gRPC, SOAP y WebSocket. La configuración cambia según el protocolo, pero la inspección de respuestas y las pruebas basadas en HTTP siguen un flujo similar.

¿Cómo escribo aserciones en Insomnia?

Use las suites de pruebas. Abra la vista Pruebas en una colección, cree una suite y añada pruebas. Cada prueba ejecuta una solicitud con:

const response = await insomnia.send();

Luego valide con expect al estilo Chai:

expect(response.status).to.equal(200);

También puede analizar el cuerpo:

const body = JSON.parse(response.data);
expect(body).to.have.property("id");

¿Qué cambió en Insomnia 8?

Insomnia 8 adoptó un modelo cloud-first por defecto, solicitando iniciar sesión con una cuenta de Kong y sincronizar proyectos en la nube. A algunos usuarios no les gustó el flujo obligatorio de cuenta ni el alejamiento de una aplicación puramente local. Versiones posteriores añadieron opciones locales más claras.

¿Puedo ejecutar pruebas de Insomnia en una pipeline de CI?

Sí. Use Inso, la herramienta de línea de comandos de Insomnia. Exporte o sincronice su colección y ejecute:

inso run test "<nombre de la suite>"

Si una prueba falla, Inso devuelve un código de salida distinto de cero, por lo que CI puede fallar la compilación automáticamente.

Cómo Simular una API para Pruebas: Guía Práctica

Roobia — Fri, 22 May 2026 07:31:40 +0000

Las pruebas que dependen de una API en vivo fallan por motivos externos a tu código: un servidor de prueba caído, un rate limit de terceros, datos modificados por otro equipo o una respuesta lenta. Simular la API elimina esa fragilidad: sustituyes el endpoint real por un mock controlado que devuelve la respuesta que necesitas, de forma repetible.

Prueba Apidog hoy

En esta guía vas a implementar un flujo práctico para simular una API en pruebas: definir el esquema, generar respuestas mock, levantar un servidor de simulación, apuntar tus tests al mock y cubrir rutas de error difíciles de reproducir con un backend real. Usaremos una API pequeña de gestión de pedidos con el endpoint GET /orders/{id}, pero el patrón aplica a cualquier API REST o GraphQL.

Cuándo simular la API

Simula la API cuando quieres probar tu propio código, no la red ni el backend real.

Casos típicos:

Tests unitarios de clientes HTTP.
Tests de integración de frontend/backend contra contratos conocidos.
Validación de parsing de respuestas.
Manejo de errores como 404, 429, 500 o timeouts.
Pruebas de retry, fallback y mensajes de error.

Mantén la API real para:

Pruebas de contrato.
Una capa pequeña de end-to-end.
Verificaciones periódicas contra producción o staging.

La división práctica es:

Mock: velocidad, aislamiento y control.
API real: confirmar que el contrato sigue siendo válido.

Para profundizar, revisa estos recursos sobre escenarios donde la simulación de API vale la pena y la diferencia entre un servidor simulado y un servidor real.

Flujo de trabajo en cinco pasos

Simular una API para pruebas suele seguir el mismo proceso:

Define el esquema de la API.
Genera respuestas simuladas estáticas o dinámicas.
Ejecuta un servidor de simulación accesible por URL.
Apunta tus pruebas al mock usando una URL base configurable.
Prueba rutas de error que el backend real no expone bajo demanda.

El ejemplo base será:

GET /orders/{id}

Paso 1: Define el esquema

Un mock solo es útil si respeta la forma real de la respuesta. Empieza por un contrato. Si ya tienes un documento OpenAPI, úsalo. Si no, define el endpoint que vas a probar.

Ejemplo mínimo para GET /orders/{id}:

paths:
  /orders/{id}:
    get:
      parameters:
        - name: id
          in: path
          required: true
          schema: { type: string }
      responses:
        '200':
          content:
            application/json:
              schema:
                type: object
                properties:
                  id: { type: string }
                  status: { type: string, enum: [pending, shipped, delivered] }
                  total: { type: number }
                  items: { type: array, items: { type: object } }
        '404':
          description: Order not found

Este esquema te da dos beneficios:

El mock sabe qué campos debe devolver.
Tus tests tienen una fuente de verdad compartida con el backend.

Cuando el contrato cambia, actualizas el esquema y regeneras las respuestas mock desde ahí. Esa disciplina es clave para mantener confiables las pruebas de contrato de API.

Paso 2: Genera respuestas simuladas

Puedes usar dos tipos de respuestas.

Respuestas estáticas

Son payloads JSON fijos. Úsalas cuando necesitas aserciones exactas.

Ejemplo:

{
  "id": "order_8842",
  "status": "shipped",
  "total": 149.99,
  "items": [
    {
      "sku": "sku_keyboard",
      "quantity": 1
    },
    {
      "sku": "sku_mouse",
      "quantity": 1
    }
  ]
}

Son ideales para tests como:

expect(order.status).toBe('shipped');
expect(order.total).toBe(149.99);

Respuestas dinámicas

Se generan por solicitud. En lugar de devolver siempre el mismo total, el mock puede producir valores realistas:

UUIDs para id.
Un valor válido del enum para status.
Cantidades monetarias plausibles para total.
Arrays con tamaños variables.

Esto ayuda a detectar errores que un fixture único puede ocultar, por ejemplo:

Parsers que fallan con strings largos.
Campos opcionales ausentes.
Arrays vacíos.
Valores nulos inesperados.

La mayoría de equipos combina ambas estrategias:

Estáticas para tests deterministas.
Dinámicas para cobertura más amplia.

Con Apidog, puedes generar endpoints mock desde el esquema. Apidog interpreta nombres de campos como email, phone o avatar y devuelve datos acordes al tipo esperado.

Si escribes payloads a mano, evita fixtures demasiado artificiales como:

{
  "id": "1",
  "status": "pending",
  "total": 0,
  "items": []
}

Mejor usa datos parecidos a producción:

{
  "id": "order_8842",
  "status": "shipped",
  "total": 149.99,
  "items": [
    {
      "sku": "sku_keyboard",
      "name": "Mechanical Keyboard",
      "quantity": 1,
      "price": 99.99
    },
    {
      "sku": "sku_mouse",
      "name": "Wireless Mouse",
      "quantity": 1,
      "price": 50
    }
  ]
}

Paso 3: Ejecuta el servidor de simulación

Una respuesta mock necesita servirse desde una URL. Tienes dos opciones principales.

Opción A: servidor mock local

Úsalo para tests unitarios e integración local. Es rápido, no depende de red externa y evita estado compartido.

Con Prism, puedes levantar un mock desde un archivo OpenAPI:

prism mock openapi.yaml
# Mock server listening on http://127.0.0.1:4010

Luego puedes probarlo con curl:

curl http://127.0.0.1:4010/orders/order_8842

Opción B: servidor mock en la nube

Úsalo cuando el mock debe ser accesible desde:

Una app móvil.
Un runner de CI.
Un colaborador externo.
Otro equipo sin acceso a tu máquina.

Apidog ofrece una URL de simulación alojada por proyecto, útil para compartir el mismo endpoint mock entre varias personas o dispositivos.

Para ejecución automatizada de tests, prefiere local cuando sea posible. Para demos, pruebas entre dispositivos o colaboración remota, usa mock en la nube.

Paso 4: Apunta tus pruebas al mock

No hardcodees la URL de producción en tus tests. Haz que la URL base sea configurable.

Ejemplo de cliente:

// orderClient.js
export async function getOrder(id, baseUrl) {
  const response = await fetch(`${baseUrl}/orders/${id}`);

  if (response.status === 404) {
    throw new Error(`Order ${id} not found`);
  }

  if (!response.ok) {
    throw new Error(`Unexpected API error: ${response.status}`);
  }

  return response.json();
}

Test apuntando al mock:

// orderClient.test.js
import { getOrder } from './orderClient.js';

const BASE_URL = process.env.API_BASE_URL || 'http://127.0.0.1:4010';

test('parses a shipped order', async () => {
  const order = await getOrder('order_8842', BASE_URL);

  expect(order.status).toBe('shipped');
  expect(typeof order.total).toBe('number');
  expect(Array.isArray(order.items)).toBe(true);
});

En local:

API_BASE_URL=http://127.0.0.1:4010 npm test

En CI puedes apuntar la misma suite a otro entorno:

API_BASE_URL=https://mock.example.com npm test

El código de producción no necesita saber si está usando un mock o una API real. Solo recibe una URL base. Este mismo patrón aplica cuando automatizas las pruebas de API en CI/CD.

Paso 5: Prueba las rutas de error

Este es el mayor valor de un mock: puedes forzar respuestas que un backend real no produce cuando tú quieres.

Configura escenarios como estos:

Escenario	La simulación devuelve	Qué verificas
Registro faltante	`404`	El cliente lanza un error claro de "no encontrado"
Fallo del servidor	`500`	El cliente reintenta y luego usa un fallback
Rate limit	`429` con `Retry-After`	El cliente espera el tiempo correcto
Respuesta lenta	`200` después de 5s	El cliente aplica timeout y se recupera
Cuerpo inválido	`200` con JSON defectuoso	El cliente falla sin crashear

Ejemplo de test para 404:

test('throws a clear error when order does not exist', async () => {
  await expect(getOrder('order_404', BASE_URL))
    .rejects
    .toThrow('Order order_404 not found');
});

Ejemplo de test para 500 con retry:

test('retries when the API returns 500', async () => {
  const order = await getOrderWithRetry('order_retry', BASE_URL, {
    retries: 2
  });

  expect(order.id).toBe('order_retry');
});

Las reglas avanzadas de simulación de Apidog permiten devolver respuestas distintas según la solicitud. Por ejemplo:

GET /orders/order_404 devuelve 404.
GET /orders/order_timeout responde con retraso.
GET /orders/order_8842 devuelve 200.

Así puedes cubrir la ruta feliz y los fallos desde un único endpoint mock. Combínalo con buenas aserciones de API para verificar comportamiento, no solo códigos de estado.

Organiza los mocks en una suite creciente

Un mock para un endpoint es fácil. Cien mocks repartidos en una suite se vuelven difíciles de mantener si no hay estructura.

Buenas prácticas:

Agrupa por servicio real

Organiza los mocks según el servicio que representan:

mocks/
  orders/
    order-shipped.json
    order-not-found.json
    order-rate-limited.json
  payments/
    payment-approved.json
    payment-declined.json

No los agrupes por test individual. Si cambia la API de pedidos, quieres actualizar una carpeta, no veinte archivos dispersos.

Nombra fixtures por escenario

Usa nombres que expliquen el caso:

order-shipped.json
order-delivered.json
order-not-found.json
order-rate-limited.json

Así, cuando falle un test, el fixture ya comunica la intención.

Versiona los mocks junto a los tests

Los mocks son parte de la prueba. Deben pasar por code review igual que el código de test.

Usa una respuesta base

Evita copiar payloads completos para cada test. Define una respuesta base y cambia solo el campo relevante.

Ejemplo:

const baseOrder = {
  id: 'order_8842',
  status: 'shipped',
  total: 149.99,
  items: [
    { sku: 'sku_keyboard', quantity: 1 },
    { sku: 'sku_mouse', quantity: 1 }
  ]
};

const pendingOrder = {
  ...baseOrder,
  status: 'pending'
};

Este enfoque reduce duplicación y hace que los cambios de contrato sean más fáciles de aplicar. La misma disciplina que mantiene una suite de pruebas para la automatización de API también mantiene sanos tus mocks.

Mantén la simulación alineada con la API real

El riesgo principal de un mock es la deriva del contrato.

Ejemplos:

El backend renombra total a amount.
Se agrega un campo obligatorio.
Cambia un enum.
Un campo deja de aceptar null.
La estructura de items cambia.

Si tus mocks no se actualizan, la suite puede seguir en verde mientras producción falla.

Para evitarlo:

1. Genera mocks desde el mismo esquema

Usa el mismo OpenAPI que publica el backend. Si el contrato cambia, el mock debe regenerarse desde esa fuente.

2. Ejecuta pruebas de contrato contra la API real

Mantén una suite pequeña que valide que la API viva sigue respetando el esquema.

Ejemplo de estrategia:

tests/
  unit/           -> usan mock local
  integration/    -> usan mock local o mock cloud
  contract/       -> usan API real de staging
  e2e/            -> usan API real con pocos casos críticos

3. Revisa mocks en cada pull request

Si una PR cambia una respuesta de API, debe cambiar también:

El esquema OpenAPI.
Los fixtures mock.
Las pruebas afectadas.

Trata la simulación como parte del contrato, no como un helper temporal.

Si quieres un entorno que concentre esquema, mock server y pruebas, puedes descargar Apidog. También puedes comparar alternativas en esta lista de herramientas de simulación de API REST.

Preguntas frecuentes

¿Debería simular la API para cada prueba?

No. Simula en pruebas unitarias e integración cuando estás validando tu propio código. Mantén un conjunto pequeño de pruebas de contrato y end-to-end contra la API real para confirmar que el mock sigue alineado con producción.

¿Cuál es la diferencia entre una respuesta mock estática y dinámica?

Una respuesta estática es un JSON fijo y predecible. Es útil para aserciones exactas.

Una respuesta dinámica se genera por solicitud con valores realistas. Es útil para descubrir errores que un único fixture no detectaría.

Lo habitual es usar ambas.

¿Cómo aseguro que mi mock siga siendo preciso?

Genera el mock desde el mismo esquema que usa el backend, idealmente OpenAPI. Luego ejecuta pruebas de contrato programadas contra la API real. Si esas pruebas fallan, el contrato o el mock deben actualizarse.

¿Puede un mock simular respuestas lentas o fallidas?

Sí. Puedes configurar respuestas como:

500 Internal Server Error.
429 Too Many Requests con Retry-After.
200 OK con retraso.
JSON mal formado.
Timeouts.

Esto permite probar lógica de retries, fallback y manejo de errores sin romper un backend real.

¿Servidor mock local o en la nube?

Usa mock local para ejecuciones de test: es rápido, aislado y sin latencia externa.

Usa mock en la nube cuando necesites acceso desde una app móvil, CI remoto, otro equipo o colaboradores externos.

Cómo Probar APIs con Postman: Guía Práctica Paso a Paso

Roobia — Fri, 22 May 2026 07:23:39 +0000

Postman es una de las herramientas más usadas para enviar solicitudes HTTP y validar el comportamiento de una API. Sirve para comprobaciones rápidas, pruebas con scripts, ejecución de colecciones y validaciones que pueden integrarse en flujos de CI. Si desarrolla o consume APIs, conviene dominar el flujo básico: crear solicitudes, parametrizarlas, escribir aserciones y ejecutarlas como suite.

Prueba Apidog hoy

En esta guía probará una API en Postman con un flujo práctico: enviar una solicitud, revisar la respuesta, escribir pruebas, usar variables para cambiar entre entornos y ejecutar una colección completa con Collection Runner. Los ejemplos usan una API pública, así que puede seguirlos sin preparar un backend propio.

Configure Postman y envíe su primera solicitud

Descargue Postman desde el sitio oficial e instale la aplicación de escritorio. Puede usarla sin cuenta para trabajar localmente, aunque iniciar sesión permite sincronizar colecciones entre dispositivos.

Para crear su primera solicitud:

Abra Postman.
Haga clic en Nuevo.
Seleccione Solicitud HTTP.
Elija el método GET.
Introduzca este endpoint:

GET https://jsonplaceholder.typicode.com/users/1

Haga clic en Enviar. En el panel de respuesta revise:

Código de estado: 200 OK
Tiempo de respuesta
Tamaño de la respuesta
Cuerpo de la respuesta en formato JSON

Cambie entre las vistas Pretty, Raw y Preview para ver el cuerpo formateado o sin procesar.

Para probar un POST:

Cambie el método a POST.
Abra la pestaña Cuerpo.
Seleccione raw.
Elija JSON como formato.
Pegue una carga útil como esta:

{
  "name": "Maria Chen",
  "email": "maria.chen@example.com"
}

Postman añadirá automáticamente el encabezado:

Content-Type: application/json

Si la API requiere autenticación, agregue encabezados en la pestaña Encabezados, por ejemplo:

Authorization: Bearer {{auth_token}}

Si necesita una referencia sobre qué códigos esperar en una API REST, consulte la guía sobre códigos de estado HTTP que las API REST deberían usar.

Organice las solicitudes en colecciones

Una solicitud aislada sirve para una verificación rápida. Para pruebas reales, agrupe solicitudes relacionadas en una colección.

Ejemplo de flujo de colección:

Crear usuario
Obtener usuario
Actualizar usuario
Eliminar usuario

Para crear una colección:

Abra Colecciones en la barra lateral.
Haga clic en el icono +.
Use un nombre específico, por ejemplo: Pruebas de humo de la API de Usuario.
Guarde cada solicitud con Ctrl/Cmd + S.
Asigne nombres claros a las solicitudes.

Puede usar carpetas dentro de una colección para separar responsabilidades:

Pruebas de humo de la API de Usuario
├── Autenticación
│   └── Login
├── Usuarios
│   ├── Crear usuario
│   ├── Obtener usuario
│   ├── Actualizar usuario
│   └── Eliminar usuario

Las colecciones también son la unidad que se comparte. Puede exportarlas como JSON o compartirlas mediante enlace si usa sincronización en la nube. Esto permite que otros miembros del equipo ejecuten exactamente las mismas solicitudes.

Además, una colección puede tener scripts compartidos:

Script de pre-solicitud: se ejecuta antes de cada solicitud.
Script de prueba: se ejecuta después de cada respuesta.

Ejemplo de script de pre-solicitud para agregar una marca de tiempo:

pm.variables.set("timestamp", Date.now());

Ejemplo de prueba a nivel de colección para limitar el tiempo de respuesta:

pm.test("Response time is acceptable", function () {
    pm.expect(pm.response.responseTime).to.be.below(1000);
});

Esto evita repetir la misma lógica en cada solicitud.

Escriba pruebas en la pestaña Pruebas

Enviar una solicitud le muestra qué respondió la API. Una prueba le dice automáticamente si esa respuesta es correcta.

En Postman, las pruebas se escriben en el área Scripts de una solicitud. En versiones anteriores, esta sección aparecía como la pestaña Tests. Postman ejecuta estos scripts después de recibir la respuesta.

El patrón principal es:

pm.test("nombre de la prueba", function () {
    // aserción
});

Ejemplos útiles:

// Verificar código de estado
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// Verificar tiempo de respuesta
pm.test("Response is under 500ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

// Verificar un campo del cuerpo JSON
pm.test("User has the expected email", function () {
    const body = pm.response.json();
    pm.expect(body.email).to.eql("maria.chen@example.com");
});

// Verificar un encabezado
pm.test("Content-Type is JSON", function () {
    pm.expect(pm.response.headers.get("Content-Type"))
      .to.include("application/json");
});

Postman usa sintaxis de Chai para las aserciones, por lo que puede usar expresiones como:

pm.expect(value).to.eql(expected);
pm.expect(value).to.include("text");
pm.expect(value).to.be.above(10);
pm.expect(value).to.be.below(500);

Después de hacer clic en Enviar, revise la pestaña Resultados de la prueba. Cada prueba aparecerá en verde o rojo.

Buenas prácticas al escribir pruebas:

Nombre cada pm.test según el comportamiento que valida.
Verifique lo que realmente rompería a un consumidor de la API.
Valide código de estado, estructura del cuerpo y campos importantes.
Evite depender de valores volátiles, como timestamps generados por el servidor.
Use el panel Snippets para insertar aserciones comunes rápidamente.

Ejemplo de prueba más robusta para una respuesta de usuario:

pm.test("Response has a valid user shape", function () {
    const body = pm.response.json();

    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("name");
    pm.expect(body).to.have.property("email");
    pm.expect(body.email).to.include("@");
});

Para profundizar en el diseño de aserciones, consulte las aserciones de API y cómo escribirlas bien. Para estructurar validaciones como casos de prueba, revise el ejemplo de caso de prueba de API.

Use entornos y variables

No conviene codificar una URL como esta en todas las solicitudes:

https://api.staging.example.com

Si luego necesita apuntar a producción, tendría que editar cada endpoint. Para evitarlo, use entornos.

Un entorno es un conjunto de variables con nombre.

Cree un entorno de staging:

Abra el gestor de entornos.
Cree un entorno llamado Staging.
Agregue una variable base_url.
Asigne este valor:

https://jsonplaceholder.typicode.com

Luego cambie su solicitud a:

GET {{base_url}}/users/1

Ahora puede crear otro entorno llamado Production con otro valor para base_url. Al cambiar el entorno activo desde el menú superior derecho, la misma colección apuntará a otro servidor.

Las variables también sirven para pasar datos entre solicitudes. Por ejemplo, una solicitud de login puede guardar un token:

pm.test("Save the auth token", function () {
    const token = pm.response.json().token;
    pm.environment.set("auth_token", token);
});

Después, cualquier solicitud puede usarlo así:

Authorization: Bearer {{auth_token}}

Este patrón permite probar flujos encadenados:

Iniciar sesión.
Guardar token.
Crear recurso autenticado.
Consultar recurso.
Eliminar recurso.

Postman ofrece varios alcances de variables:

Alcance	Uso recomendado
Variables de entorno	Valores que cambian entre staging, producción o local
Variables de colección	Valores compartidos por una colección
Variables globales	Valores disponibles en todas partes
Variables locales	Valores temporales durante una ejecución

Use el alcance más limitado posible. Esto reduce errores al cambiar de entorno o ejecutar colecciones compartidas.

Ejecute una colección completa con el Collection Runner

Hacer clic en Enviar en cada solicitud no escala. Para ejecutar una suite completa, use Collection Runner.

Pasos:

Abra una colección.
Haga clic en Ejecutar.
Seleccione el entorno.
Defina el número de iteraciones.
Adjunte un archivo de datos si lo necesita.
Haga clic en Ejecutar.

Postman ejecutará las solicitudes de arriba hacia abajo y mostrará un resumen de:

Solicitudes ejecutadas
Pruebas aprobadas
Pruebas fallidas
Errores por solicitud

El orden de las solicitudes importa. Para flujos autenticados, coloque primero la solicitud de login:

1. Login
2. Crear usuario
3. Obtener usuario
4. Actualizar usuario
5. Eliminar usuario

Así, Login puede guardar auth_token y las demás solicitudes pueden reutilizarlo.

También puede preparar y limpiar datos durante la ejecución:

1. Crear recurso de prueba
2. Ejecutar validaciones
3. Eliminar recurso de prueba

Esto convierte la colección en un recorrido automatizado de extremo a extremo.

Pruebas basadas en datos

Collection Runner permite adjuntar archivos CSV o JSON. Cada fila se convierte en una iteración.

Ejemplo CSV:

email,password,expected_status
user@example.com,correct-password,200
user@example.com,wrong-password,401
missing@example.com,password,404

En la solicitud puede usar:

{
  "email": "{{email}}",
  "password": "{{password}}"
}

Y en la prueba:

pm.test("Status code matches expected result", function () {
    pm.response.to.have.status(Number(pm.iterationData.get("expected_status")));
});

Este enfoque evita duplicar solicitudes para probar muchas combinaciones de entrada.

El artículo sobre pruebas de API basadas en datos con CSV y JSON cubre el patrón con más detalle. Para ejecutar la misma colección en CI sin interfaz gráfica, Postman proporciona Newman, descrito en la comparación Newman versus Postman.

Donde Postman se vuelve pesado y qué considerar

Postman funciona bien para pruebas exploratorias y suites pequeñas o medianas. A medida que el proyecto crece, suelen aparecer dos fricciones:

Las aserciones viven en JavaScript, lo que puede dificultar el trabajo de QA o perfiles no desarrolladores.
El diseño de API, las pruebas, el mocking y la documentación pueden quedar separados, aumentando el riesgo de divergencia entre contrato y pruebas.

Apidog es una plataforma API todo en uno que aborda esos puntos. Importa colecciones de Postman directamente, permite construir aserciones visuales sin código y también admite scripts cuando se necesitan. Al centralizar diseño, depuración, mocking, pruebas y documentación sobre una misma fuente de verdad, ayuda a mantener las pruebas alineadas con la especificación real de la API.

Si está evaluando alternativas, el resumen de alternativas a Postman para pruebas de API compara ventajas y desventajas. También puede descargar Apidog e importar una colección existente para compararlo con su flujo actual.

Esto no significa que deba abandonar Postman. Sigue siendo una opción sólida para comprobaciones rápidas y equipos que ya lo usan. Lo importante es elegir la herramienta adecuada para el tamaño del flujo, el perfil del equipo y el nivel de automatización que necesita.

Preguntas frecuentes

¿Necesito escribir código para probar APIs en Postman?

Para enviar solicitudes y leer respuestas, no. Para aserciones automatizadas, sí. La pestaña de pruebas usa JavaScript y el objeto pm.

Puede empezar copiando snippets integrados de Postman, por ejemplo:

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

Si necesita un constructor visual de aserciones sin código, una plataforma dedicada como Apidog puede cubrir ese flujo.

¿Cuál es la diferencia entre una colección de Postman y un entorno?

Una colección agrupa solicitudes y pruebas. Un entorno contiene variables como base_url, auth_token o user_id.

Ejemplo:

GET {{base_url}}/users/{{user_id}}

La colección define qué se envía. El entorno define contra qué valores se ejecuta.

¿Cómo ejecuto las pruebas de Postman automáticamente en CI?

Use Newman, el ejecutor de línea de comandos de Postman.

Exporte su colección y entorno, y ejecute:

newman run collection.json -e environment.json

Newman devuelve un código distinto de cero si alguna prueba falla, lo que permite fallar el pipeline de CI.

La guía sobre cómo automatizar pruebas de API en CI/CD explica cómo integrarlo en un pipeline.

¿Puede Postman probar más que APIs REST?

Sí. Postman soporta GraphQL, gRPC, WebSocket y SOAP, además de HTTP y REST. La configuración cambia según el protocolo, pero el enfoque general sigue siendo el mismo: enviar solicitud, inspeccionar respuesta y validar con pruebas.

¿Cuántas aserciones debería tener una solicitud?

Las suficientes para confirmar que la respuesta es correcta, sin volver la prueba frágil.

Una base práctica:

Código de estado
Tiempo de respuesta
Estructura del cuerpo
Campos críticos para el consumidor

Ejemplo:

pm.test("User response is valid", function () {
    const body = pm.response.json();

    pm.response.to.have.status(200);
    pm.expect(body).to.have.property("id");
    pm.expect(body).to.have.property("email");
});

Mantenga cada pm.test enfocado en una expectativa clara para que una falla indique exactamente qué se rompió.

Cómo usar Assert en Node.js: Guía práctica

Roobia — Fri, 22 May 2026 07:23:30 +0000

Cada framework de pruebas que has utilizado, ya sea Jest, Mocha o node:test, se basa en una idea simple: defines lo que esperas y lanzas un error si la realidad no coincide. Node.js incluye esa idea como un módulo incorporado llamado assert: sin instalación, sin dependencias, solo lo importas y empiezas a validar suposiciones.

Prueba Apidog hoy

El módulo assert sirve para comprobaciones rápidas en scripts, pruebas unitarias simples y validación de respuestas HTTP. También ayuda a entender qué hace realmente una aserción antes de usar un framework más grande. En esta guía verás cómo importar assert, comparar valores, validar objetos, probar errores, manejar código asíncrono y aplicar las mismas ideas a pruebas de API.

Qué hace el módulo `assert`

Una aserción declara que algo debe ser verdadero para que el programa sea correcto.

Por ejemplo:

assert.strictEqual(total, 100);

Esto significa: "total debe ser exactamente 100".

Si la condición se cumple, no pasa nada. Si falla, Node.js lanza un AssertionError.

Importa siempre la versión estricta:

const assert = require('node:assert/strict');

// Con ES modules:
// import assert from 'node:assert/strict';

La aserción más básica verifica que un valor sea truthy:

const user = getUser(42);

assert(user, 'getUser debe devolver un objeto de usuario');

El segundo argumento es el mensaje de error. Úsalo siempre. Un fallo con contexto es mucho más útil que un AssertionError genérico.

Comprender esto también ayuda cuando pasas a aserciones de API en herramientas especializadas.

Usa modo estricto, no modo legado

assert tiene dos modos:

const looseAssert = require('node:assert');
const strictAssert = require('node:assert/strict');

El modo legado usa igualdad flexible (==) en métodos como equal:

const assert = require('node:assert');

assert.equal(1, '1'); // pasa

Esto pasa porque JavaScript convierte tipos automáticamente. En pruebas, eso suele ocultar errores.

El modo estricto usa igualdad estricta (===):

const assert = require('node:assert/strict');

assert.equal(1, '1'); // lanza AssertionError

En la práctica:

const looseAssert = require('node:assert');
looseAssert.equal(1, '1'); // pasa, pero puede ser peligroso

const assert = require('node:assert/strict');
assert.equal(1, '1'); // falla, como debería

Recomendación: usa siempre node:assert/strict. En este modo, assert.equal se comporta como assert.strictEqual.

Comparar valores primitivos con `strictEqual`

Usa assert.strictEqual(actual, expected) para números, strings, booleanos y otros valores primitivos.

const assert = require('node:assert/strict');

function priceWithTax(price, rate) {
  return price + price * rate;
}

assert.strictEqual(
  priceWithTax(100, 0.08),
  108,
  'el cálculo del impuesto debe sumar un 8%'
);

assert.strictEqual(
  typeof priceWithTax(100, 0.08),
  'number',
  'el resultado debe ser un número'
);

Para comprobar que dos valores no sean iguales, usa notStrictEqual:

const before = getCacheKey();

refreshCache();

const after = getCacheKey();

assert.notStrictEqual(
  before,
  after,
  'la clave de caché debe cambiar después de la actualización'
);

No uses strictEqual para comparar objetos o arrays por contenido. En JavaScript, dos objetos con la misma estructura siguen siendo referencias distintas:

assert.strictEqual({ id: 1 }, { id: 1 }); // falla

Para eso necesitas igualdad profunda.

Comparar objetos y arrays con `deepStrictEqual`

Usa assert.deepStrictEqual(actual, expected) para comparar estructuras completas.

const assert = require('node:assert/strict');

function buildOrder(id, items) {
  return {
    id,
    items,
    status: 'pending'
  };
}

assert.deepStrictEqual(
  buildOrder(7, ['keyboard', 'mouse']),
  {
    id: 7,
    items: ['keyboard', 'mouse'],
    status: 'pending'
  },
  'el objeto de pedido debe coincidir con la forma esperada'
);

Este método compara claves, valores y tipos de forma recursiva.

Por ejemplo, esto falla:

assert.deepStrictEqual(
  { id: 7 },
  { id: '7' },
  'el id debe ser numérico'
);

Falla porque 7 y '7' no tienen el mismo tipo. Esa estrictez es útil: detecta cambios silenciosos en tus datos.

Usa deepStrictEqual para:

objetos devueltos por funciones
arrays
cuerpos JSON de APIs
estructuras anidadas
fixtures esperados

Ejemplo con respuesta JSON:

assert.deepStrictEqual(
  body.user,
  {
    id: 101,
    name: 'Dana Lee',
    active: true
  },
  'el usuario debe coincidir con la respuesta esperada'
);

Si tienes muchos casos de entrada, puedes escalar este patrón con pruebas parametrizadas o datos externos. Esta guía sobre pruebas de API basadas en datos con CSV y JSON explica ese enfoque.

Cuando deepStrictEqual falla, Node.js muestra un diff con las propiedades distintas. Para objetos grandes, ese diff suele ser mucho más útil que escribir múltiples strictEqual campo por campo.

Validar existencia y formato con `ok` y `match`

No todas las pruebas necesitan comparar un objeto completo. A veces solo quieres validar que un valor exista o que tenga cierto formato.

Usa assert.ok(value) para comprobar valores truthy:

assert.ok(user, 'el usuario debe existir');
assert.ok(user.email, 'el usuario debe incluir email');
assert.ok(items.length > 0, 'la lista de items no debe estar vacía');

Usa assert.match(string, regexp) para validar strings con expresiones regulares:

const assert = require('node:assert/strict');

function generateOrderId() {
  return 'ORD-' + Date.now();
}

const id = generateOrderId();

assert.match(
  id,
  /^ORD-\d+$/,
  'el id de pedido debe ser ORD- seguido de dígitos'
);

assert.ok(
  id.length > 4,
  'el id de pedido no debe estar vacío'
);

También existe assert.doesNotMatch:

assert.doesNotMatch(
  username,
  /\s/,
  'el username no debe contener espacios'
);

Este patrón es especialmente útil en pruebas de API, donde algunos valores cambian en cada respuesta:

timestamps
IDs generados
tokens
UUIDs
URLs firmadas

En esos casos, valida la forma, no el valor exacto.

Probar que una función lanza errores con `throws`

A veces el comportamiento correcto es fallar. Para eso usa assert.throws(fn, expectedError).

const assert = require('node:assert/strict');

function parsePort(value) {
  const port = Number(value);

  if (!Number.isInteger(port) || port < 1 || port > 65535) {
    throw new RangeError('port must be an integer between 1 and 65535');
  }

  return port;
}

Valida que una entrada inválida lance el tipo correcto de error:

assert.throws(
  () => parsePort('70000'),
  RangeError,
  'un puerto fuera de rango debe lanzar RangeError'
);

También puedes validar el mensaje con una expresión regular:

assert.throws(
  () => parsePort('abc'),
  /must be an integer/,
  'un puerto no numérico debe lanzar un error descriptivo'
);

Y puedes comprobar que una entrada válida no lance error:

assert.doesNotThrow(
  () => parsePort('8080'),
  'un puerto válido no debe lanzar un error'
);

Punto importante: pasa una función, no el resultado de ejecutarla.

Correcto:

assert.throws(() => parsePort('70000'), RangeError);

Incorrecto:

assert.throws(parsePort('70000'), RangeError);

En el segundo caso, parsePort('70000') se ejecuta antes de que assert.throws pueda capturar el error.

Probar promesas rechazadas con `rejects`

En código asíncrono, una promesa rechazada equivale a un error lanzado. Para eso usa:

assert.rejects
assert.doesNotReject

Ambos devuelven promesas, así que debes usar await.

const assert = require('node:assert/strict');

async function fetchUser(id) {
  if (typeof id !== 'number') {
    throw new TypeError('id must be a number');
  }

  return {
    id,
    name: 'Dana Lee'
  };
}

async function runTests() {
  await assert.rejects(
    fetchUser('not-a-number'),
    TypeError,
    'el id de tipo string debe ser rechazado'
  );

  await assert.doesNotReject(
    fetchUser(101),
    'un id válido debe resolverse correctamente'
  );
}

runTests();

También puedes pasar una función async:

await assert.rejects(
  async () => fetchUser('not-a-number'),
  TypeError,
  'debe rechazar ids no numéricos'
);

No olvides await. Sin await, la prueba puede terminar antes de que la aserción se resuelva, y el fallo aparecerá como un rechazo no manejado en lugar de un error claro.

Usar `assert` para probar respuestas de API

assert funciona bien para validar una solicitud HTTP simple: código de estado, headers y cuerpo JSON.

Ejemplo con fetch:

const assert = require('node:assert/strict');

async function testGetUser() {
  const res = await fetch('https://api.example.com/users/101');

  assert.strictEqual(
    res.status,
    200,
    'GET /users/101 debe devolver 200'
  );

  const body = await res.json();

  assert.strictEqual(
    typeof body.id,
    'number',
    'el id debe ser un número'
  );

  assert.strictEqual(
    body.id,
    101,
    'el id debe coincidir con el usuario solicitado'
  );

  assert.ok(
    body.name,
    'la respuesta debe incluir un nombre'
  );

  assert.ok(
    Array.isArray(body.roles),
    'roles debe ser un array'
  );
}

testGetUser().then(
  () => console.log('Prueba de API superada'),
  (err) => {
    console.error('Prueba de API fallida:', err.message);
    process.exitCode = 1;
  }
);

También puedes validar headers:

assert.match(
  res.headers.get('content-type'),
  /application\/json/,
  'la respuesta debe ser JSON'
);

Y validar una estructura parcial del cuerpo:

assert.deepStrictEqual(
  {
    id: body.id,
    active: body.active
  },
  {
    id: 101,
    active: true
  },
  'los campos principales del usuario deben coincidir'
);

Este patrón es útil para scripts pequeños y comprobaciones rápidas. Para una suite real de APIs, normalmente necesitarás más cosas:

gestión de entornos
autenticación reutilizable
reintentos
ejecución en CI/CD
reportes
escenarios con múltiples requests
datos de prueba

Para ese siguiente paso, revisa estas guías sobre cómo escribir scripts de prueba automatizados y el framework de automatización de API pytest.

Si no quieres construir manualmente todo el arnés de pruebas, Apidog te permite definir solicitudes de API y adjuntar aserciones visuales sobre códigos de estado, encabezados y campos JSON sin escribir todo el código de aserción. También puedes encadenar solicitudes en escenarios automatizados, ejecutarlos en CI/CD y usar scripts personalizados cuando necesites más control. Puedes descargar Apidog y usarlo gratis. Junto con Apidog, el módulo assert de Node.js cubre tanto comprobaciones rápidas como suites más completas.

Preguntas frecuentes

¿Necesito instalar el módulo `assert`?

No. assert está incorporado en Node.js.

Impórtalo así:

const assert = require('node:assert/strict');

O, si usas ES modules:

import assert from 'node:assert/strict';

No necesitas instalar ningún paquete npm. El prefijo node: indica explícitamente que estás cargando un módulo central de Node.js.

¿Cuál es la diferencia entre `assert.equal` y `assert.strictEqual`?

En modo legado, assert.equal usa igualdad flexible (==) y assert.strictEqual usa igualdad estricta (===).

En modo estricto:

const assert = require('node:assert/strict');

assert.equal se comporta igual que assert.strictEqual.

Recomendación: usa siempre node:assert/strict para evitar que la coerción de tipos haga pasar una prueba por accidente.

¿Cuándo debo usar `deepStrictEqual` en lugar de `strictEqual`?

Usa strictEqual para valores primitivos:

assert.strictEqual(statusCode, 200);
assert.strictEqual(typeof user.id, 'number');
assert.strictEqual(user.active, true);

Usa deepStrictEqual para objetos y arrays:

assert.deepStrictEqual(user.roles, ['admin', 'editor']);
assert.deepStrictEqual(response.body, expectedBody);

strictEqual compara referencias. Dos objetos separados con el mismo contenido no son iguales por referencia.

¿Debo usar `assert` o un framework como Jest?

Depende del caso.

Usa assert para:

scripts rápidos
pruebas pequeñas
validaciones internas
aprender fundamentos de testing
comprobar respuestas HTTP simples

Usa un framework cuando necesites:

organización de suites
hooks como beforeEach y afterEach
mocks
reportes
watch mode
integración con herramientas de cobertura

Node.js también incluye node:test, un runner incorporado que combina muy bien con assert y no requiere dependencias externas.

¿Cómo afirmo que una función asíncrona se rechaza?

Usa assert.rejects con await:

await assert.rejects(
  fetchUser('invalid-id'),
  TypeError,
  'debe rechazar ids inválidos'
);

También puedes validar el mensaje:

await assert.rejects(
  fetchUser('invalid-id'),
  /id must be a number/,
  'debe devolver un mensaje de error claro'
);

Sin await, la aserción puede no ejecutarse correctamente antes de que termine la prueba.

Herramientas Gratuitas Online para Probar APIs: Guía Práctica

Roobia — Fri, 22 May 2026 07:23:02 +0000

No necesita una licencia de pago para probar una API correctamente. Con una herramienta gratuita —en navegador, escritorio u open source— puede enviar solicitudes, validar códigos de estado, comprobar el cuerpo de la respuesta y ejecutar una pequeña suite de regresión antes de publicar. La clave no es encontrar “una herramienta gratis”, sino elegir una cuyo plan gratuito no bloquee las funciones que necesitará cuando el proyecto crezca.

Prueba Apidog hoy

Esta guía compara herramientas gratuitas de prueba de API que funcionan bien en escenarios reales. Para cada una, verá qué ofrece el nivel gratuito, dónde están los límites y cómo evaluarla con un flujo práctico antes de adoptarla.

Qué significa realmente “gratuito en línea”

“En línea” puede significar tres cosas distintas:

Herramienta 100% navegador: no instala nada y trabaja desde una pestaña.
Aplicación de escritorio con sincronización en la nube: instala un cliente, pero sus colecciones se sincronizan.
Herramienta open source: gratuita, pero normalmente la ejecuta o aloja usted.

Antes de elegir, revise estos límites frecuentes:

Colaboración: muchas herramientas son gratis para uso individual, pero cobran cuando se suma el equipo.
Historial y monitorización: algunos planes gratuitos guardan pocos días de resultados.
Automatización: las ejecuciones programadas o desde CI/CD suelen estar medidas.

Si está definiendo su estrategia de pruebas, empiece por distinguir entre un escenario de prueba y un caso de prueba.

Herramientas gratuitas que merece la pena probar

Apidog

Apidog es una plataforma todo en uno para diseño, depuración, pruebas automatizadas, mocking y documentación de APIs.

En el plan gratuito puede trabajar con:

REST
GraphQL
SOAP
WebSocket
Escenarios de prueba con solicitudes encadenadas
Aserciones visuales
Servidor de mock integrado
Sin tarjeta de crédito

Un flujo práctico en Apidog sería:

Crear o importar una API.
Definir variables de entorno como base_url y token.
Enviar una solicitud inicial, por ejemplo POST /login.
Extraer un valor de la respuesta, como access_token.
Reutilizarlo en una segunda solicitud, por ejemplo GET /profile.
Añadir aserciones sobre código de estado y campos del JSON.
Ejecutar el escenario completo como una suite.

Ejemplo de comprobaciones que debería añadir:

status = 200
body.user.id existe
body.user.email contiene "@"
response time < 500ms

Apidog se ejecuta como aplicación de escritorio en Windows, macOS y Linux, con sincronización en la nube. Es útil si quiere diseñar, simular, documentar y probar APIs sin unir varias herramientas. Puede descargar Apidog y empezar en el nivel gratuito.

Hoppscotch

Hoppscotch es una herramienta basada en navegador y open source. No requiere instalación y funciona bien para pruebas rápidas de REST, GraphQL y WebSocket.

Úsela si necesita:

Enviar solicitudes desde el navegador.
Crear colecciones simples.
Gestionar entornos.
Probar APIs sin configurar una aplicación de escritorio.

Flujo mínimo recomendado:

1. Crear un entorno "staging".
2. Definir base_url.
3. Enviar GET {{base_url}}/health.
4. Verificar status 200.
5. Guardar la solicitud en una colección.

Su punto fuerte es la velocidad y la baja fricción. Su límite principal está en colaboración avanzada, historial y automatización compleja.

Postman nivel gratuito

Postman es una opción conocida para muchos equipos. El nivel gratuito cubre solicitudes manuales, colecciones, entornos y una cantidad limitada de ejecuciones automatizadas mensuales.

Un ejemplo básico de test en Postman:

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

pm.test("la respuesta contiene userId", function () {
  const json = pm.response.json();
  pm.expect(json).to.have.property("userId");
});

Es una buena opción si su equipo ya conoce su flujo de trabajo. El límite suele aparecer en colaboración, volumen de llamadas y ejecuciones automatizadas. Si lo está comparando con otras opciones, revise esta guía sobre cómo probar APIs con Postman.

Insomnia

Insomnia es un cliente de escritorio enfocado en depuración para REST, GraphQL y gRPC. Su interfaz es limpia y cómoda para pruebas individuales o suites pequeñas.

Úselo si quiere:

Depurar endpoints rápidamente.
Trabajar desde escritorio.
Mantener una interfaz simple.
Probar REST, GraphQL o gRPC sin demasiada configuración.

Un flujo típico:

1. Crear una colección por servicio.
2. Definir entornos para local, staging y producción.
3. Guardar tokens como variables.
4. Probar endpoints críticos.
5. Añadir scripts o comprobaciones donde aplique.

Para pasos prácticos, consulte el tutorial sobre cómo usar Insomnia para probar una API.

SoapUI open source

SoapUI sigue siendo una opción sólida para APIs SOAP y también soporta REST. La edición open source es gratuita y fuerte en pruebas funcionales y basadas en datos.

Tiene sentido si trabaja con:

Servicios SOAP heredados.
WSDL.
XML.
Pruebas funcionales con múltiples datos de entrada.

Ejemplo de validación típica en SOAP:

1. Importar el WSDL.
2. Generar operaciones.
3. Crear una solicitud SOAP.
4. Ejecutarla contra el endpoint.
5. Validar status HTTP.
6. Validar nodos XML específicos en la respuesta.

Su desventaja es que es una aplicación Java más pesada, y las funciones de reporting más avanzadas están en ReadyAPI.

Thunder Client

Thunder Client es una extensión para VS Code. Si ya trabaja dentro del editor, puede probar APIs sin cambiar de contexto.

Úselo si quiere:

Ejecutar solicitudes desde VS Code.
Guardar colecciones junto al proyecto.
Probar endpoints durante el desarrollo.
Evitar abrir una aplicación separada.

Flujo recomendado:

1. Instalar la extensión en VS Code.
2. Crear una colección por módulo.
3. Configurar variables de entorno.
4. Ejecutar solicitudes desde el editor.
5. Añadir pruebas sin scripts donde aplique.

El nivel gratuito funciona bien para solicitudes individuales y colecciones. La sincronización basada en Git y algunas funciones de equipo son de pago.

Tabla comparativa

Herramienta	Tipo	Protocolos	Fortaleza del nivel gratuito	Límite principal
Apidog	Escritorio + sincronización en la nube	REST, GraphQL, SOAP, WebSocket	Diseño, pruebas, mock y documentación	Equipos grandes necesitan puestos de pago
Hoppscotch	Navegador, open source	REST, GraphQL, WebSocket	Cero instalación y rapidez	Automatización más ligera
Postman	Escritorio + nube	REST, GraphQL, gRPC	Familiar y bien documentado	Ejecuciones medidas y puestos de pago
Insomnia	Escritorio	REST, GraphQL, gRPC	UX limpia para depuración	Suite de pruebas más limitada
SoapUI	Escritorio, open source	SOAP, REST	Pruebas SOAP y data-driven	Aplicación pesada e informes de pago
Thunder Client	Extensión de VS Code	REST, GraphQL	Comodidad dentro del editor	Sincronización y funciones de equipo de pago

Cómo elegir una herramienta

Empiece por los protocolos.

Si solo usa REST, casi todas sirven.
Si usa GraphQL, revise soporte para queries, variables y entornos.
Si usa SOAP, considere un probador de API SOAP en línea o SoapUI.
Si usa WebSocket, limite la búsqueda a herramientas que lo soporten explícitamente, como Apidog o Hoppscotch.

Después evalúe navegador vs escritorio:

Use navegador si quiere cero instalación.
Use escritorio si necesita acceder a localhost, redes privadas, archivos grandes o trabajar offline.
Use escritorio con sincronización en la nube si quiere acceso local y continuidad entre máquinas.

Luego pruebe el mismo flujo en cada herramienta:

1. Crear un entorno "staging".
2. Definir base_url.
3. Enviar POST /login.
4. Guardar access_token desde la respuesta.
5. Enviar GET /me usando ese token.
6. Validar status 200.
7. Validar un campo del cuerpo.
8. Ejecutar ambas solicitudes como una suite.

La herramienta que haga este flujo con menos fricción probablemente sea la mejor para su equipo. Para mejorar esas verificaciones, revise cómo escribir aserciones de API útiles.

Herramientas gratuitas y pipelines de CI

Una herramienta gratuita puede servir para CI/CD, pero debe revisar el volumen permitido.

Ejemplos comunes:

Postman exporta colecciones que puede ejecutar con Newman.
Hoppscotch tiene CLI.
Apidog ejecuta escenarios desde su propio ejecutor y se integra con pipelines.

Un patrón básico de CI sería:

name: api-tests

on:
  push:
    branches:
      - main

jobs:
  test-api:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Ejecutar pruebas de API
        run: |
          echo "Ejecute aquí su CLI o runner de pruebas de API"

El límite del nivel gratuito suele ser la cantidad de ejecuciones automatizadas, no la capacidad de automatizar. Una suite nocturna puede ser suficiente. Una suite en cada commit dentro de un repositorio con mucho tráfico puede requerir un plan de pago.

Si su objetivo es CI/CD, esta guía sobre automatización de pruebas de API en CI/CD cubre los patrones principales.

Qué debe validar una prueba de API

Evite llamar “prueba” a una solicitud que solo se ejecuta. Una prueba útil afirma algo concreto.

Como mínimo, valide:

1. Código de estado.
2. Estructura del cuerpo.
3. Campos obligatorios.
4. Valores críticos para el negocio.
5. Tiempo de respuesta aceptable.

Ejemplo de aserciones para un endpoint GET /orders/{id}:

status = 200
body.id existe
body.status está en ["pending", "paid", "cancelled"]
body.total > 0
body.currency = "USD"
response time < 700ms

Los códigos de estado HTTP que debe usar una API REST son una buena base para definir estas comprobaciones. Una prueba que solo valida 200 puede pasar aunque la respuesta sea incompleta o incorrecta.

Errores comunes con herramientas gratuitas

1. Elegir una herramienta solo para “probarla”

No elija una herramienta que sabe que reemplazará pronto. Evalúe si el plan gratuito puede acompañar al proyecto durante meses.

2. No usar entornos desde el primer día

Evite esto:

https://staging.api.com/users
https://staging.api.com/orders
https://staging.api.com/payments

Use variables:

{{base_url}}/users
{{base_url}}/orders
{{base_url}}/payments

Y defina entornos:

local:    http://localhost:3000
staging:  https://staging.api.com
prod:     https://api.com

3. Codificar tokens en cada solicitud

Evite duplicar tokens manualmente. Guárdelos como variables:

Authorization: Bearer {{access_token}}

Si la herramienta lo permite, extraiga access_token automáticamente desde la respuesta de login.

4. Ignorar la latencia

Si un endpoint que debería responder en 100ms tarda 800ms, eso es una señal. No necesita una herramienta de carga para detectar regresiones simples.

Para pruebas de carga más deliberadas, consulte este tutorial de pruebas de rendimiento de API.

5. No exportar el trabajo

Los planes gratuitos pueden cambiar. Exporte sus colecciones y manténgalas en control de versiones cuando sea posible.

Ejemplo de estructura:

api-tests/
  collections/
    users.json
    orders.json
  environments/
    local.json
    staging.json
  README.md

Navegador vs escritorio en detalle

Las herramientas de navegador son cómodas porque no requieren instalación. Sin embargo, están sujetas al sandbox de seguridad del navegador. Eso puede afectar:

Llamadas a localhost.
Acceso a redes privadas.
Cargas de archivos grandes.
Payloads binarios.
Comportamiento CORS.

Antes de adoptar una herramienta de navegador, pruebe que puede acceder a su API local:

GET http://localhost:3000/health

Las aplicaciones de escritorio evitan muchos de esos límites. Pueden abrir conexiones de red directamente, acceder a servicios locales y trabajar mejor con cargas grandes. También pueden seguir funcionando sin conexión.

El coste es instalar y actualizar la aplicación. Por eso muchos equipos prefieren una aplicación de escritorio con sincronización en la nube: mantiene el acceso local y permite continuar el trabajo en varias máquinas.

Cómo mantener saludable una suite gratuita de pruebas

Una suite se degrada si no se mantiene. Los endpoints cambian, los campos se renombran y las aserciones quedan obsoletas.

Haga una revisión periódica:

Cada 2-4 semanas:
1. Eliminar endpoints obsoletos.
2. Actualizar URLs o rutas modificadas.
3. Revisar aserciones rotas.
4. Renombrar pruebas ambiguas.
5. Mover solicitudes a carpetas por flujo.
6. Exportar la colección actualizada.

Use nombres descriptivos.

Evite:

prueba 1
test users
request final

Prefiera:

crear usuario con email válido
rechazar login con contraseña incorrecta
crear pedido con moneda inválida
obtener perfil con token expirado

Agrupe por flujos reales:

Autenticación/
  login exitoso
  login con contraseña incorrecta
  refresh token

Pedidos/
  crear pedido
  pagar pedido
  cancelar pedido

La misma disciplina que ayuda a definir un caso de prueba también mejora una colección de solicitudes de API.

Preguntas frecuentes

¿Las herramientas gratuitas de prueba de API son suficientes para producción?

Sí, para muchos equipos. Los niveles gratuitos suelen cubrir creación de solicitudes, entornos, aserciones y automatización básica. Normalmente se pasa a un plan de pago por colaboración, historial más largo o CI/CD de alto volumen.

¿Puedo probar APIs SOAP con herramientas gratuitas?

Sí. Apidog soporta SOAP en su nivel gratuito, y SoapUI open source está diseñado para ese tipo de servicios. SOAP suele requerir XML, envoltorios específicos y a veces WSDL, por lo que conviene usar una herramienta con soporte explícito. Puede consultar la especificación oficial de SOAP del W3C para detalles del protocolo.

¿Qué diferencia hay entre una herramienta de navegador y una de escritorio?

Una herramienta de navegador funciona sin instalación, pero puede estar limitada por seguridad del navegador, CORS o acceso a red local. Una herramienta de escritorio puede acceder mejor a localhost, redes privadas, archivos grandes y trabajo offline.

¿Las herramientas gratuitas soportan suites automatizadas?

La mayoría sí. Puede encadenar solicitudes, agregar aserciones y ejecutarlas como suite. Postman puede combinarse con Newman, mientras que Hoppscotch y Apidog tienen sus propios ejecutores. El límite suele ser la cantidad de ejecuciones automatizadas disponibles en el plan gratuito.

¿Con qué herramienta debería empezar un equipo pequeño?

Empiece con una herramienta que cubra diseño, pruebas y mocking para evitar añadir productos más adelante. Apidog y Hoppscotch son buenas opciones para equipos pequeños en sus niveles gratuitos. Ejecute el mismo flujo de dos solicitudes encadenadas con aserciones y quédese con la que resulte más fluida para su stack.

Cómo Probar Conexiones WebSocket con Curl y Otras Herramientas

Roobia — Fri, 22 May 2026 07:23:00 +0000

WebSocket te da un canal persistente y bidireccional entre cliente y servidor sobre una única conexión TCP. A diferencia de REST, no pruebas una respuesta aislada: pruebas un flujo de mensajes, eventos enviados por el servidor, autenticación, timeouts y cierre de conexión.

Prueba Apidog hoy

Esta guía muestra cómo probar WebSocket de forma práctica: qué puedes hacer con curl, cuándo usar websocat y cuándo conviene usar una GUI como Apidog. Todos los comandos están listos para copiar.

Por qué las pruebas de WebSocket no son como las pruebas REST

Una prueba REST suele ser una transacción:

Envías una solicitud.
Recibes una respuesta.
Validás el estado, headers y body.
Terminas.

Una prueba WebSocket es una conversación:

Abres una conexión.
Envías uno o varios mensajes.
Recibes respuestas.
Esperas mensajes enviados por el servidor.
Mantienes o cierras la conexión.
Validás el código de cierre.

Eso cambia lo que debes verificar:

Que el handshake HTTP se actualiza correctamente a WebSocket.
Que el servidor acepta la autenticación.
Que el primer mensaje válido recibe la respuesta esperada.
Que los mensajes enviados por el servidor llegan sin nuevas solicitudes.
Que los errores se reportan de forma controlada.
Que el cierre usa un código esperado.

Una herramienta pensada para solicitudes únicas tiene limitaciones aquí. Por eso curl sirve para comprobaciones rápidas, pero no reemplaza a una herramienta WebSocket real.

Si quieres estructurar estas pruebas, la diferencia entre un escenario de prueba y un caso de prueba encaja bien con WebSocket: una conversación completa es un escenario; un mensaje específico con respuesta esperada es un caso.

El handshake de WebSocket

Toda conexión WebSocket empieza como una solicitud HTTP que pide actualizar el protocolo.

El cliente envía headers como:

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13

Si el servidor acepta, responde:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

Después de ese 101, la conexión deja de ser HTTP y empieza a usar tramas WebSocket, definidas en RFC 6455.

Esta es la principal limitación de curl: puede iniciar el handshake, pero no siempre es cómodo para enviar, recibir y procesar tramas WebSocket durante una sesión interactiva.

Probando WebSocket con curl

Las versiones modernas de curl, desde la 7.86, incluyen soporte experimental para WebSocket.

Primero, verifica tu versión:

curl --version

Si tienes curl 7.86 o posterior, puedes probar el handshake contra un endpoint WebSocket.

Ejemplo con un servidor echo público:

curl --include --no-buffer \
  --header "Connection: Upgrade" \
  --header "Upgrade: websocket" \
  --header "Sec-WebSocket-Version: 13" \
  --header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  https://echo.websocket.org

Qué revisar:

--include muestra los headers de respuesta.
Debes ver HTTP/1.1 101 Switching Protocols.
--no-buffer evita que curl retenga la salida, algo importante en conexiones de streaming.

Para conexiones seguras, usa wss:// del mismo modo que usarías https://.

curl es útil para una comprobación rápida:

curl --include --no-buffer wss://example.com/socket

Úsalo para responder preguntas como:

¿El endpoint existe?
¿El servidor acepta el upgrade?
¿La autenticación falla antes del handshake?
¿La ruta devuelve 404, 401, 403 o 101?

Pero para sesiones interactivas con varios mensajes, curl no es la opción más cómoda. Si quieres integrar este tipo de comprobaciones en una pipeline, revisa cómo automatizar pruebas de API en CI/CD.

Probando WebSocket con websocat

websocat es una herramienta de línea de comandos diseñada específicamente para WebSocket. Funciona como un netcat para conexiones ws:// y wss://.

Instalación en macOS:

brew install websocat

Instalación con Cargo:

cargo install websocat

Conectarte a un endpoint echo:

websocat wss://echo.websocket.org

Esto abre una sesión interactiva. Escribe un mensaje, presiona Enter y verás la respuesta del servidor.

Ejemplo:

hello
hello

Enviar un solo mensaje y salir

Para enviar un mensaje desde un script:

echo '{"action":"subscribe","channel":"prices"}' | websocat wss://stream.example.com/feed

Esto sirve para pruebas simples de request/response.

Enviar headers de autenticación

Muchos endpoints WebSocket requieren tokens en headers:

websocat \
  --header "Authorization: Bearer your-token-here" \
  wss://api.example.com/socket

También puedes usar parámetros de consulta si tu API los requiere:

websocat "wss://api.example.com/socket?token=your-token-here"

Probar mensajes JSON

Puedes enviar JSON directamente:

websocat wss://api.example.com/socket

Luego escribe:

{"action":"subscribe","channel":"orders"}

Si el servidor responde correctamente, deberías ver algo como:

{"type":"subscribed","channel":"orders"}

Usar websocat en scripts

Un patrón básico para automatizar una comprobación:

response=$(echo '{"type":"ping"}' | websocat -1 wss://api.example.com/socket)

echo "$response"

if echo "$response" | grep -q '"type":"pong"'; then
  echo "WebSocket OK"
  exit 0
else
  echo "WebSocket failed"
  exit 1
fi

websocat cubre la mayoría de los casos que curl no maneja bien: sesiones interactivas, headers personalizados, entrada por stdin, salida por stdout y pruebas automatizadas.

Para validar payloads de forma consistente, las ideas de aserciones de API útiles también aplican a mensajes WebSocket.

Probando WebSocket con una herramienta GUI

La línea de comandos es ideal para scripts, CI y comprobaciones rápidas. Pero para pruebas exploratorias, una GUI suele ser más eficiente.

Usa una GUI cuando necesitas:

Ver una línea de tiempo de mensajes enviados y recibidos.
Enviar JSON estructurado sin escribir todo en la terminal.
Mantener una conexión abierta mientras pruebas distintos mensajes.
Configurar headers, query params o tokens de autenticación.
Compartir una prueba reproducible con otro desarrollador.

Apidog incluye un cliente WebSocket dedicado. Puedes ingresar una URL ws:// o wss://, conectarte y ver cada mensaje en una línea de tiempo con resaltado JSON. También puedes guardar conexiones, configurar headers y parámetros de consulta, y probar WebSocket junto con REST, GraphQL y SOAP en la misma aplicación.

Puedes descargar Apidog para probar endpoints WebSocket con una vista visual de mensajes.

Como regla práctica:

Usa curl para confirmar accesibilidad y handshake.
Usa websocat para pruebas técnicas desde terminal.
Usa una GUI para exploración, depuración visual y colaboración.

Si quieres comparar opciones, este resumen de herramientas gratuitas de prueba de API en línea incluye alternativas que manejan WebSocket.

Lista de verificación para probar WebSocket

Usa esta checklist cuando pruebes un endpoint WebSocket.

1. Confirma el upgrade

La conexión debe devolver:

HTTP/1.1 101 Switching Protocols

Si no recibes 101, revisa:

URL incorrecta.
Ruta incorrecta.
Headers faltantes.
Autenticación fallida.
Proxy o gateway bloqueando el upgrade.

2. Verifica la autenticación

Confirma dónde espera el servidor el token:

Header:

websocat \
  --header "Authorization: Bearer your-token-here" \
  wss://api.example.com/socket

Query param:

websocat "wss://api.example.com/socket?token=your-token-here"

Una conexión que se abre y se cierra inmediatamente suele indicar token inválido, expirado o enviado en el lugar incorrecto.

3. Envía un mensaje conocido

Usa una carga útil válida para tu API:

{"action":"subscribe","channel":"prices"}

Verifica que la respuesta tenga la forma esperada:

{"type":"subscribed","channel":"prices"}

4. Verifica mensajes enviados por el servidor

Después de suscribirte, no envíes nada más. Espera mensajes entrantes:

{"type":"price.updated","symbol":"BTCUSD","price":65000}

Esto valida el comportamiento principal de WebSocket: entrega de eventos sin solicitud adicional.

5. Prueba errores

Envía un mensaje inválido:

{"action":"unknown"}

El servidor debería responder con un error controlado, no cerrar la conexión sin explicación:

{"type":"error","message":"Unsupported action"}

6. Prueba el cierre

Cierra la conexión y revisa el código de cierre.

Códigos comunes:

1000: cierre normal.
1006: cierre anormal sin handshake limpio.
1011: error interno del servidor.

Para organizar estas comprobaciones en un conjunto repetible, la guía sobre cómo construir suites de prueba de API también aplica a flujos WebSocket.

Depurando una conexión WebSocket que no funciona

Cuando una conexión WebSocket falla, revisa estos puntos en orden.

1. Verifica el esquema de la URL

Usa el esquema correcto:

ws://example.com/socket
wss://example.com/socket

ws:// no está cifrado.

wss:// usa TLS.

Si tu aplicación corre sobre HTTPS, los navegadores pueden bloquear conexiones ws:// porque mezclan contenido seguro e inseguro. En producción, usa wss://.

2. Revisa el resultado del handshake

Si no recibes 101, el servidor no aceptó la actualización.

Códigos típicos:

400: headers de upgrade faltantes o mal formados.
401: autenticación requerida.
403: autenticación rechazada o permisos insuficientes.
404: ruta incorrecta.
101: upgrade correcto.

Con curl:

curl --include --no-buffer wss://api.example.com/socket

Con websocat, usa modo verboso si necesitas más detalle:

websocat -v wss://api.example.com/socket

3. Revisa timeouts y ping/pong

Si el handshake funciona pero la conexión se cierra segundos después, puede ser por inactividad.

Muchos servidores esperan frames ping/pong para confirmar que el cliente sigue vivo. También puede haber un proxy o balanceador de carga cerrando conexiones inactivas.

Revisa:

Timeout del servidor.
Timeout del proxy.
Configuración del load balancer.
Reglas de idle timeout.
Si el cliente responde a ping/pong.

4. Lee el código de cierre

Los códigos de cierre están definidos en RFC 6455.

Ejemplos:

1000: cierre normal.
1001: endpoint se va.
1002: error de protocolo.
1003: tipo de datos no soportado.
1006: cierre anormal.
1011: error interno del servidor.

El código de cierre suele indicar si el problema está en el cliente, el servidor, la red o la autenticación.

Automatizando comprobaciones WebSocket

Una prueba manual confirma que el endpoint funciona ahora. Para evitar regresiones, necesitas ejecutarla de forma automática.

Un flujo mínimo automatizado debería validar:

La conexión se actualiza a WebSocket.
Un mensaje conocido recibe la respuesta esperada.
Una suscripción recibe al menos un evento dentro de un timeout.
La prueba falla con código distinto de cero si algo no coincide.

Ejemplo simple con websocat:

#!/usr/bin/env bash

set -euo pipefail

URL="wss://api.example.com/socket"
MESSAGE='{"type":"ping"}'
EXPECTED='"type":"pong"'

response=$(echo "$MESSAGE" | websocat -1 "$URL")

echo "Response: $response"

if echo "$response" | grep -q "$EXPECTED"; then
  echo "WebSocket check passed"
else
  echo "WebSocket check failed"
  exit 1
fi

Ese script puede ejecutarse en CI como cualquier otro paso:

./test-websocket.sh

Mantén estas pruebas enfocadas. No intentes validar todos los mensajes posibles de una conexión larga. Es mejor tener pruebas pequeñas y estables:

Una prueba para handshake.
Una prueba para autenticación.
Una prueba para request/response.
Una prueba para suscripción.
Una prueba para error controlado.

La misma disciplina que mantiene claro un caso de prueba también mantiene fiables las comprobaciones WebSocket: prueba una cosa específica y hazla verificable.

Preguntas frecuentes

¿Puede curl probar conexiones WebSocket?

Parcialmente. curl 7.86 y posteriores tiene soporte experimental para WebSocket. Sirve para comprobar si un endpoint es accesible y si el handshake se completa. Para sesiones interactivas con muchos mensajes, websocat o una GUI como Apidog son mejores opciones.

¿Cuál es la diferencia entre ws y wss?

ws:// es WebSocket sin cifrado.

wss:// es WebSocket cifrado con TLS.

Es la misma diferencia práctica que entre HTTP y HTTPS. Usa wss:// fuera del desarrollo local, porque ws:// envía mensajes en texto plano.

¿Por qué mi conexión WebSocket se abre y luego se cierra inmediatamente?

La causa más común es autenticación fallida. El servidor puede aceptar la conexión TCP y luego cerrarla si el token falta, expiró o está en el lugar incorrecto.

Revisa:

Header Authorization.
Parámetros de consulta.
Expiración del token.
Código de cierre.
Logs del servidor.

¿Es websocat mejor que curl para probar WebSocket?

Sí, para WebSocket específicamente. websocat está diseñado para este protocolo, soporta sesiones interactivas, headers personalizados, redirección de entrada/salida y manejo correcto de tramas. Usa curl para comprobaciones rápidas y websocat para pruebas reales desde terminal.

¿Cómo pruebo que un servidor envía mensajes sin una solicitud?

Abre la conexión, suscríbete al canal o evento requerido y espera sin enviar más mensajes.

Con websocat:

websocat wss://api.example.com/socket

Envía:

{"action":"subscribe","channel":"orders"}

Luego observa si llegan eventos sin más entrada:

{"type":"order.created","id":"ord_123"}

Con una GUI como Apidog, esos mensajes aparecen en la línea de tiempo de la conexión.

Comparativa de Herramientas Online para Mocking de APIs: Apidog, Mockoon, WireMock, Beeceptor y Postman

Roobia — Fri, 22 May 2026 07:22:30 +0000

Una herramienta de simulación de API en línea te permite trabajar contra un endpoint funcional antes de que exista el backend. Apuntas tu frontend, app móvil o suite de pruebas a una URL alojada y recibes respuestas realistas. La clave es que Apidog, Mockoon, WireMock, Beeceptor y Postman difieren mucho en alojamiento, generación de datos, lógica condicional y esfuerzo de configuración.

Prueba Apidog hoy

Esta guía compara esas cinco herramientas desde una perspectiva práctica: dónde se ejecuta el mock, cómo se configuran respuestas, qué tan fácil es generar datos dinámicos y en qué escenarios conviene usar cada una. Al final encontrarás una tabla comparativa, criterios de selección y preguntas frecuentes para elegir sin adivinar.

Qué significa “en línea” para un servidor de simulación

“En línea” puede significar dos cosas distintas:

Mock en la nube: se ejecuta en la infraestructura del proveedor y expone una URL pública.
Mock local: se ejecuta en tu máquina, contenedor o runner de CI.

La diferencia afecta directamente el flujo de trabajo:

Necesidad	Mejor opción
Compartir un endpoint con un equipo remoto	URL pública
Probar desde una app móvil real	URL pública
Ejecutar pruebas aisladas en CI	Local o contenedor
Trabajar sin conexión	Local
Hacer una demo rápida a cliente	URL pública

Antes de elegir una herramienta, decide si necesitas una URL pública, un mock local o ambos. Esta decisión se relaciona con la comparación más amplia entre servidor de simulación versus servidor real.

Además del alojamiento, evalúa cinco criterios:

Generación automática de datos: ¿la herramienta rellena respuestas realistas o tienes que escribir cada payload?
Respuestas condicionales: ¿puede responder distinto según headers, query params, body o ruta?
Esfuerzo de configuración: ¿usas una GUI, una colección, JSON stubs o código?
Integración con el diseño de API: ¿el mock se mantiene alineado con la especificación?
Uso en CI/CD: ¿puede ejecutarse en pipelines o contenedores?

Apidog

Apidog genera endpoints de simulación a partir del diseño de tu API. Defines un endpoint y obtienes una URL de mock sin configurar un servidor aparte.

El flujo típico es:

Diseña el endpoint.
Define parámetros, body y schema de respuesta.
Usa la URL de mock generada.
Conecta frontend, app móvil o pruebas automatizadas a esa URL.

Apidog incluye Smart Mock, que genera datos a partir de los nombres de campo. Por ejemplo:

{
  "id": 123,
  "email": "user@example.com",
  "created_at": "2025-01-15T10:30:00Z",
  "avatar": "https://example.com/avatar.png"
}

Si el schema contiene campos como email, created_at, phone o avatar, Apidog puede devolver datos coherentes con esos nombres en lugar de valores genéricos como "string".

Para escenarios más complejos, Advanced Mock permite devolver respuestas distintas según la solicitud. Por ejemplo:

200 para un usuario existente.
404 para un ID inexistente.
422 para una entrada inválida conocida.

Esto resulta útil para probar flujos de éxito y error sin esperar a que el backend implemente todos los casos.

Apidog también combina diseño, mock, depuración y pruebas de contrato de API en un mismo proyecto. Esto reduce el riesgo de que el mock se desvíe de la especificación cuando el contrato cambia.

Úsalo si: quieres un mock generado desde un diseño real de API, con datos realistas, URL compartible y flujo integrado de pruebas.

Mockoon

Mockoon es una aplicación de escritorio gratuita y de código abierto para crear mocks locales rápidamente.

El flujo básico es:

Crea un entorno en la app de escritorio.
Define rutas como GET /users o POST /login.
Añade respuestas estáticas o dinámicas.
Ejecuta el servidor en un puerto local.
Apunta tu cliente a http://localhost:<puerto>.

Mockoon soporta plantillas dinámicas con Faker.js. Por ejemplo, puedes devolver datos similares a:

{
  "id": "{{faker 'number.int'}}",
  "name": "{{faker 'person.fullName'}}",
  "email": "{{faker 'internet.email'}}"
}

También permite respuestas basadas en reglas, por ejemplo:

Devolver una respuesta si existe un header específico.
Cambiar el payload según un query param.
Simular latencia con retrasos configurables.

Mockoon se ejecuta localmente por defecto. Si necesitas usarlo en CI o en un servidor propio, puedes usar su CLI o imagen de Docker. No ofrece una URL pública de nube de primera parte.

Úsalo si: quieres un mock local rápido, gratuito, sin registro y sin dependencia de la nube.

WireMock

WireMock es una herramienta madura y orientada a código para crear mocks precisos. Tiene raíces fuertes en la JVM, pero puede ejecutarse como proceso independiente, contenedor o servicio.

WireMock destaca en la coincidencia de solicitudes. Puedes definir stubs que respondan según:

Ruta.
Método HTTP.
Headers.
Cookies.
Query params.
Body JSON.
Patrones o expresiones.

Un stub típico en WireMock se parece a esto:

{
  "request": {
    "method": "GET",
    "url": "/users/123"
  },
  "response": {
    "status": 200,
    "jsonBody": {
      "id": 123,
      "name": "Ada Lovelace"
    },
    "headers": {
      "Content-Type": "application/json"
    }
  }
}

WireMock también incluye plantillas de respuesta, inyección de fallos, proxy, grabación y reproducción.

Puedes ejecutarlo:

Localmente.
En Docker.
En CI/CD.
En WireMock Cloud de pago si necesitas una URL alojada.

Su principal coste es la configuración. Normalmente defines stubs en JSON o código, no desde una GUI simple. A cambio, obtienes control granular y mocks versionables junto al código, algo útil para la automatización de pruebas de API en CI/CD.

Úsalo si: necesitas mocks programables, versionados y con coincidencia precisa de solicitudes.

Beeceptor

Beeceptor es una de las formas más rápidas de obtener una URL pública de mock.

El flujo es simple:

Nombras un endpoint desde el navegador.
Beeceptor genera una URL alojada.
Defines reglas de respuesta.
Inspeccionas las solicitudes entrantes desde la interfaz web.

Es útil para:

Demos rápidas.
Probar webhooks.
Compartir una URL temporal.
Interceptar callbacks de terceros.
Simular parcialmente un backend existente.

Beeceptor también puede actuar como proxy hacia un backend real e interceptar solo rutas seleccionadas. Esto permite, por ejemplo, usar el backend real para la mayoría de endpoints y mockear solo una ruta que aún no está lista.

La limitación principal es que el uso serio requiere plan de pago, y al estar basado en la nube no es ideal para trabajo sin conexión ni ejecuciones de CI completamente aisladas.

Úsalo si: necesitas una URL pública rápida, inspección de requests y configuración mínima.

Postman

Postman permite crear un servidor de simulación a partir de una colección guardada.

El flujo habitual es:

Creas o reutilizas una colección.
Añades ejemplos de respuesta a cada request.
Publicas la colección como mock server.
Postman aloja una URL pública.
El mock devuelve el ejemplo que mejor coincide con la solicitud entrante.

Ejemplo de uso:

GET https://<mock-id>.mock.pstmn.io/users/123

La ventaja es la conveniencia si tu equipo ya trabaja con colecciones de Postman. El mock vive junto a las requests existentes.

La desventaja es que la configuración es más manual que en herramientas orientadas a mocks dinámicos. Debes definir cada ejemplo de respuesta, y la lógica condicional es más limitada. Los valores dinámicos existen mediante variables de Postman, pero requieren configuración manual.

Si estás evaluando opciones, también puede ser útil revisar alternativas a Postman para pruebas de API.

Úsalo si: tu equipo ya está estandarizado en Postman y solo necesita mocks alojados simples a partir de colecciones.

Comparación lado a lado

Herramienta	Alojamiento	Datos auto-generados	Respuestas condicionales	Esfuerzo de configuración	Nivel gratuito
Apidog	Nube + local	Sí, a partir de nombres de campo	Sí, Advanced Mock	Muy bajo	Generoso
Mockoon	Local + auto-alojado	Sí, Faker.js	Sí, basado en reglas	Bajo	Completamente gratuito
WireMock	Local, contenedor, nube de pago	Con plantillas	Sí, coincidencia profunda	Alto	Núcleo de código abierto
Beeceptor	Solo en la nube	Plantillas limitadas	Sí, reglas de simulación	Muy bajo	Volumen limitado
Postman	Nube	Manual, mediante variables	Limitado	Medio	Llamadas limitadas

Cómo elegir

Empieza por el alojamiento.

Si necesitas una URL pública para una app móvil, un compañero remoto o una demo, considera:

Apidog.
Beeceptor.
Postman.

Si solo necesitas pruebas locales o CI aislado, considera:

Mockoon.
WireMock.

Luego decide entre rapidez y control.

Si quieres...	Elige...
URL pública en menos de un minuto	Beeceptor
Mock local gratuito sin cuenta	Mockoon
Stubs versionados y precisos	WireMock
Mock desde una colección existente	Postman
Mock generado desde el diseño de API	Apidog

Finalmente, revisa dónde vive el mock respecto al contrato de API. Un mock independiente funciona para un stub temporal. Pero si el diseño cambia cada semana, un mock separado puede quedarse obsoleto rápido.

Apidog mantiene la simulación generada a partir del diseño de API. Si el contrato cambia, el mock se actualiza con el diseño. Si además necesitas datos realistas sin escribir payloads a mano, esa automatización elimina buena parte del trabajo repetitivo.

Para probar el flujo completo de diseño, mock y pruebas, puedes descargar Apidog. También puedes revisar esta guía sobre herramientas de simulación de API REST y esta lista de herramientas gratuitas de pruebas de API en línea.

Una nota sobre la calidad de los datos simulados

Un mock que devuelve esto para todo no ayuda demasiado:

{
  "name": "string",
  "id": 0
}

Técnicamente es una respuesta válida, pero no prueba cómo se comporta el cliente con datos realistas.

Evalúa la calidad de datos con una prueba simple:

Genera un endpoint de mock.
Envía una solicitud real.
Inspecciona el body.
Comprueba si los datos se parecen a producción.
Prueba casos de error, listas vacías y valores límite.

Las herramientas se diferencian bastante aquí:

Apidog infiere datos desde nombres de campo como email, phone, created_at o avatar.
Mockoon puede lograr datos realistas con plantillas Faker.js.
WireMock depende de plantillas y stubs definidos por ti.
Postman requiere ejemplos y variables configuradas manualmente.
Beeceptor ofrece reglas y plantillas, pero está más orientado a rapidez y endpoints públicos.

Si los datos simulados no parecen reales, tus pruebas contra ellos tampoco reflejarán bien el comportamiento del cliente.

Preguntas frecuentes

¿Cuál es la diferencia entre una simulación de API en la nube y una local?

Una simulación en la nube se ejecuta en servidores del proveedor y expone una URL pública. Es útil para compartir, probar apps móviles y hacer demos.

Una simulación local se ejecuta en tu máquina, contenedor o runner de CI. Suele ser más rápida, funciona sin conexión y mantiene las pruebas aisladas.

¿Qué herramienta de simulación requiere la menor configuración?

Beeceptor y Apidog son las opciones más rápidas.

Beeceptor genera una URL pública en cuanto nombras un endpoint. Apidog genera un mock automáticamente desde el diseño de API, sin configurar un servidor de simulación separado.

¿WireMock es solo para proyectos Java?

No. WireMock tiene raíces en la JVM, pero puede ejecutarse como proceso independiente, imagen Docker o servicio con API HTTP. Sus stubs en JSON son agnósticos del lenguaje, por lo que también sirve para equipos políglotas.

¿Estas herramientas pueden generar datos realistas automáticamente?

Sí, pero con diferencias.

Apidog infiere datos desde nombres de campo como email o phone. Mockoon usa plantillas Faker.js. WireMock admite plantillas de respuesta. Postman usa variables y ejemplos que debes configurar manualmente.

¿Debería usar el servidor de simulación de Postman si mi equipo ya usa Postman?

Sí, si necesitas algo simple y tu colección ya está en Postman. Es el camino de menor resistencia.

Pero si necesitas datos generados automáticamente, respuestas condicionales avanzadas o mocks más conectados al diseño de API, una herramienta dedicada puede ahorrar más tiempo.

Cómo usar Talend API Tester para pruebas de API

Roobia — Fri, 22 May 2026 07:22:28 +0000

Talend API Tester es una extensión de Chrome para enviar solicitudes HTTP e inspeccionar respuestas sin salir del navegador. Antes se llamaba Restlet Client, y muchos desarrolladores aún la usan para comprobaciones rápidas porque solo requiere instalar la extensión. Soporta APIs REST, métodos HTTP comunes y escenarios para encadenar varias solicitudes.

Prueba Apidog hoy

En esta guía vas a usar Talend API Tester en un flujo práctico: instalar la extensión, enviar solicitudes GET y POST, organizar llamadas en proyectos y servicios, crear un escenario con varias solicitudes en secuencia y añadir aserciones para validar respuestas automáticamente. Los ejemplos usan una API pública para que puedas seguirlos sin preparar backend propio.

Instalar la extensión y enviar una solicitud

Talend API Tester está disponible en la Chrome Web Store. Busca “Talend API Tester” y haz clic en Añadir a Chrome. También funciona en navegadores basados en Chromium, como Edge o Brave.

Después de instalarla:

Abre Talend API Tester desde el menú de extensiones.
Fíjala a la barra de herramientas si la vas a usar con frecuencia.
Abre el panel principal de la extensión.

La interfaz se divide en:

Una barra lateral izquierda para proyectos, servicios y solicitudes guardadas.
Un panel derecho para construir la solicitud.
Un selector de método HTTP.
Un campo de URL.
Secciones para encabezados, cuerpo, autenticación y respuesta.

Para enviar una solicitud básica, selecciona GET y usa este endpoint de JSONPlaceholder:

GET https://jsonplaceholder.typicode.com/users/1

Haz clic en Enviar. Talend API Tester mostrará:

Código de estado.
Tiempo de respuesta.
Encabezados.
Cuerpo de la respuesta.
JSON o XML formateado de forma legible.

Para probar una solicitud POST, cambia el método a POST, abre la sección Cuerpo y selecciona application/json. Usa una carga útil como esta:

{
  "name": "Priya Nair",
  "email": "priya.nair@example.com"
}

Si tu API requiere autenticación, añade un encabezado en la sección Encabezados:

Authorization: Bearer TU_TOKEN

También puedes usar los ayudantes de autenticación integrados para esquemas como Basic, Digest, OAuth y Bearer si prefieres no escribir el encabezado manualmente.

Organizar solicitudes en proyectos y servicios

Para pruebas rápidas, unas cuantas solicitudes sueltas son suficientes. Pero cuando empiezas a validar varios endpoints, necesitas estructura. Talend API Tester organiza el trabajo en:

Proyectos: agrupan una API o un conjunto de pruebas.
Servicios: agrupan endpoints relacionados dentro de un proyecto.
Solicitudes: llamadas HTTP concretas guardadas dentro de un servicio.

Un flujo recomendado:

Crea un proyecto llamado, por ejemplo, API de Usuario.
Dentro del proyecto, crea servicios como:
- Usuarios
- Pedidos
- Autenticación
Guarda cada solicitud en el servicio correspondiente.
Define una URL base en el servicio si varios endpoints comparten el mismo host.

Por ejemplo, si el servicio usa esta URL base:

https://jsonplaceholder.typicode.com

Las solicitudes pueden guardar solo la ruta:

/users/1
/posts/1
/comments/1

Esto evita duplicación y facilita cambios posteriores.

Esta estructura importa por dos razones:

Te permite encontrar solicitudes sin buscar entre decenas de llamadas sin nombre.
Es necesaria para construir escenarios, porque los escenarios reutilizan solicitudes guardadas.

Talend API Tester también soporta variables de entorno. Puedes definir una variable como:

host=https://staging.example.com

Y usarla en tus solicitudes:

{{host}}/users/1

Luego puedes crear otro entorno con:

host=https://api.example.com

Así cambias de staging a producción sin editar cada URL manualmente. Esto reduce errores, especialmente cuando trabajas con endpoints destructivos como DELETE.

También puedes importar trabajo existente. Talend API Tester acepta:

Colecciones de Postman.
Definiciones Swagger.
Definiciones OpenAPI.
Archivos HAR.

Si ya tienes una especificación o una colección exportada, impórtala en lugar de recrear todas las solicitudes a mano. Para estructurar mejor tus validaciones, consulta esta guía de ejemplo de caso de prueba de API.

Construir un escenario para ejecutar solicitudes en secuencia

Una solicitud aislada responde una pregunta concreta: “¿este endpoint responde?”. Pero muchas pruebas reales validan un flujo completo:

Crear un registro.
Leerlo.
Actualizarlo.
Eliminarlo.

Talend API Tester maneja estos flujos con escenarios.

Un escenario es una lista ordenada de solicitudes guardadas. Para crear uno:

Guarda las solicitudes que quieres reutilizar.
Crea un escenario desde la barra lateral.
Añade las solicitudes en el orden correcto.
Ejecuta el escenario.
Revisa el resultado de cada paso.

Ejemplo de flujo:

1. POST /users
2. GET /users/{id}
3. PUT /users/{id}
4. DELETE /users/{id}

La parte más útil es pasar datos entre pasos. Por ejemplo, si una solicitud de creación devuelve un id, puedes extraer ese valor y usarlo en una solicitud posterior.

Respuesta de ejemplo:

{
  "id": 123,
  "name": "Priya Nair",
  "email": "priya.nair@example.com"
}

Ese id puede guardarse como variable y reutilizarse en la siguiente URL:

/users/{{userId}}

Así pruebas flujos con estado, no solo llamadas aisladas.

Los escenarios también soportan lógica condicional y repetición. Puedes hacer que un paso se ejecute solo si otro devolvió un estado concreto, o repetir una solicitud para validar un endpoint varias veces. Combinado con variables, esto permite modelar flujos más realistas:

1. Autenticarse
2. Crear un recurso
3. Validar que se puede leer
4. Actualizarlo
5. Confirmar el cambio
6. Eliminarlo

Ejecutar este flujo completo da una señal más útil que lanzar cada solicitud manualmente. El artículo sobre escenario de prueba versus caso de prueba explica la diferencia entre una verificación única y un flujo de varios pasos, que aquí se corresponde con solicitudes individuales frente a escenarios.

Añadir aserciones para que la herramienta verifique las respuestas

Ejecutar una solicitud te muestra qué respondió la API. Las aserciones verifican si esa respuesta es correcta.

En Talend API Tester puedes añadir aserciones a una solicitud guardada. En lugar de escribir código, las configuras desde un formulario. Las más comunes son:

El código de estado es igual al esperado, por ejemplo 200 o 201.
El tiempo de respuesta está por debajo de un umbral, por ejemplo 500 ms.
Un campo del cuerpo coincide con un valor esperado.
Un encabezado existe o tiene un valor concreto.

Ejemplo de criterios para una solicitud GET /users/1:

Status code = 200
Response time < 500 ms
Body field $.id = 1
Header Content-Type contains application/json

Cada aserción se evalúa cuando ejecutas la solicitud, ya sea individualmente o dentro de un escenario. El panel de resultados marca cada aserción como aprobada o fallida.

Esto convierte un escenario en una prueba de regresión repetible. En lugar de leer manualmente cada respuesta, ejecutas el escenario y revisas qué pasos pasaron o fallaron.

La ventaja de las aserciones basadas en formularios es que son accesibles para testers o desarrolladores que no quieren escribir scripts. La limitación es que el vocabulario es más básico que el de una herramienta basada en código. Si necesitas validar condiciones complejas, valores calculados o relaciones entre múltiples campos, puedes alcanzar el límite de la herramienta.

Para la mayoría de comprobaciones diarias, suele bastar con:

Status code esperado
Tiempo de respuesta máximo
Campos clave del cuerpo
Encabezados importantes

Para decidir qué conviene validar, revisa esta guía sobre aserciones de API.

Leer la respuesta correctamente

Aunque añadas aserciones, necesitas saber interpretar una respuesta HTTP. Revisa siempre estas cuatro partes.

1. Código de estado

Es la primera señal de resultado:

2xx: éxito.
4xx: error del cliente o de la solicitud.
5xx: error del servidor.

Ejemplos comunes:

200 OK
201 Created
400 Bad Request
401 Unauthorized
404 Not Found
500 Internal Server Error

Una referencia como la guía sobre códigos de estado HTTP que las APIs REST deben usar ayuda a interpretar casos menos obvios.

2. Tiempo de respuesta

Talend API Tester muestra cuánto tardó la solicitud. Un endpoint puede devolver datos correctos y aun así fallar desde el punto de vista de rendimiento.

Por ejemplo, podrías definir una regla interna como:

GET /users/{id} debe responder en menos de 500 ms

Si empieza a responder en 2 o 3 segundos, hay un problema aunque el código sea 200.

3. Encabezados

Los encabezados explican comportamiento que no siempre aparece en el cuerpo. Revisa especialmente:

Content-Type
Cache-Control
Authorization
Access-Control-Allow-Origin
X-RateLimit-Limit
X-RateLimit-Remaining

Pueden ayudarte a diagnosticar problemas de CORS, caché, autenticación o límites de tasa.

4. Cuerpo

El cuerpo contiene los datos reales, normalmente en JSON o XML. Valida:

Campos obligatorios.
Tipos de datos.
Valores esperados.
Estructura del objeto.
Mensajes de error.

Ejemplo:

{
  "id": 1,
  "name": "Leanne Graham",
  "email": "Sincere@april.biz"
}

No basta con que la API responda. Debe responder con el estado, el rendimiento, los encabezados y el cuerpo correctos.

Cuando una extensión de Chrome no es suficiente

Talend API Tester es práctico para comprobaciones rápidas desde el navegador. Sus límites aparecen cuando el trabajo crece:

Está ligado a Chrome.
No está pensado para ejecutarse sin interfaz gráfica en CI/CD.
Sus aserciones son útiles, pero más básicas que las de una plataforma de pruebas completa.
No cubre diseño de API, mocking o documentación como parte de un mismo flujo.

Apidog es una plataforma de API todo en uno que cubre esas brechas. Es una aplicación independiente, importa Postman, OpenAPI y otros formatos igual que Talend API Tester, y añade constructor visual de aserciones, servidores mock, escenarios de prueba automatizados y documentación generada dentro de un mismo proyecto.

Como la especificación y las pruebas comparten una única fuente de verdad, es más fácil evitar que la documentación, los mocks y los casos de prueba se desalineen. Puedes descargar Apidog e importar tus solicitudes existentes para comparar el flujo de trabajo. Para revisar más alternativas, consulta esta comparación de herramientas gratuitas de prueba de API en línea.

Talend API Tester sigue siendo una buena opción para verificaciones rápidas en el navegador. La clave es ajustar la herramienta al tamaño y la etapa de tu trabajo de pruebas.

Preguntas frecuentes

¿Es Talend API Tester lo mismo que Restlet Client?

Sí. Talend API Tester es la versión renombrada de la herramienta que antes se llamaba Restlet Client. Sigue siendo una extensión de Chrome para enviar solicitudes HTTP, organizarlas y ejecutar escenarios con aserciones.

¿Es Talend API Tester gratuito?

Existe una versión gratuita disponible en la Chrome Web Store. Cubre el envío de solicitudes, la organización en proyectos y la creación de escenarios con aserciones. Las versiones de pago históricamente añadían funciones de equipo y límites mayores. Para la mayoría de pruebas individuales, la versión gratuita es suficiente.

¿Puede Talend API Tester ejecutar pruebas en CI/CD?

No directamente. Es una extensión de Chrome y se ejecuta dentro del navegador, por lo que no está pensada para correr sin interfaz gráfica en un pipeline. Para pruebas automatizadas en cada commit, necesitas una herramienta con ejecutor de línea de comandos. Esta guía sobre cómo automatizar pruebas de API en CI/CD muestra cómo suele configurarse ese flujo.

¿Qué formatos puede importar Talend API Tester?

Puede importar:

Colecciones de Postman.
Definiciones Swagger.
Definiciones OpenAPI.
Archivos HAR.

Esto permite reutilizar especificaciones o exportaciones existentes en lugar de recrear cada solicitud manualmente.

¿En qué se diferencia un escenario de una única solicitud?

Una solicitud única envía una llamada HTTP y muestra una respuesta. Un escenario ejecuta una lista ordenada de solicitudes y puede pasar datos capturados de una respuesta a pasos posteriores.

Una solicitud aislada sirve para validar un endpoint. Un escenario sirve para probar un flujo completo, como crear un recurso, leerlo, actualizarlo y eliminarlo.

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

Roobia — Fri, 22 May 2026 07:21:55 +0000

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

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

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}

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

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

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}

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

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}

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}

Luego impórtalo desde tu archivo de pruebas:

*** Settings ***
Resource          common.robot

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

Una estructura típica puede ser:

tests/
  users.robot
  orders.robot
resources/
  common.robot
  auth.robot
  users_keywords.robot
  orders_keywords.robot

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/

Para inyectar variables de entorno, usa --variable:

robot --outputdir results --variable BASE_URL:https://staging.example.com/v1 tests/

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}

Ejecutar solo smoke tests:

robot --include smoke --outputdir results tests/

Patrón típico para CI:

Instalar Python.
Instalar dependencias con pip.
Ejecutar robot.
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.

Cómo Escribir Casos de Prueba API: Plantilla y Ejemplo

Roobia — Fri, 22 May 2026 07:21:53 +0000

Una API inestable rara vez falla porque “nadie la probó”. Falla porque la prueba validó lo incorrecto: solo un 200 OK, ningún campo del cuerpo, ningún contrato, ningún tiempo de respuesta. Un buen caso de prueba de API te ayuda a detectar un contrato roto antes del release, no después de una incidencia en producción.

Prueba Apidog hoy

En esta guía verás qué es un caso de prueba de API, qué campos debe incluir y cómo escribir uno desde cero. También construiremos un ejemplo completo para POST /auth/login y luego lo llevaremos a Apidog sin escribir scripts.

Qué es realmente un caso de prueba de API

Un caso de prueba de API define:

entradas concretas,
una acción específica,
resultados esperados,
criterios de validación.

No es lo mismo que un escenario de prueba.

Un escenario dice:

Verificar inicio de sesión de usuario.

Un caso de prueba dice:

Enviar credenciales válidas a POST /auth/login y confirmar una respuesta 200, un JWT no vacío en el cuerpo y un tiempo de respuesta menor a 800 ms.

La diferencia importa porque cada caso debe validar un solo comportamiento. Si una prueba grande falla, todavía tienes que investigar qué parte se rompió. Si un caso enfocado falla, el nombre del caso ya apunta al problema.

Si necesitas separar mejor estos conceptos, revisa escenario de prueba vs caso de prueba y caso de prueba vs script de prueba.

Una suite de pruebas de API debería cubrir, como mínimo, estos ángulos:

Funcional: el endpoint devuelve los datos correctos para una entrada válida.
Negativo: rechaza entradas inválidas con el código y error esperados.
Rendimiento: responde dentro de un tiempo aceptable.
Seguridad: aplica autenticación, autorización y límites de entrada.
Contrato: la respuesta coincide con el esquema documentado.

Una suite que solo valida el camino feliz pasará hasta que un usuario real envíe una contraseña vacía.

Por qué necesitas una plantilla de caso de prueba

Escribir casos desde cero genera inconsistencias. Un tester valida códigos de estado, otro valida cuerpos de respuesta, otro escribe “debería funcionar”.

Una plantilla evita eso porque obliga a capturar la misma información cada vez.

Beneficios prácticos:

Cobertura auditable

Si todos los casos tienen los mismos campos, las lagunas son visibles.
Onboarding más rápido

Un nuevo miembro del equipo aprende un formato único, no cinco estilos distintos.
Reutilización entre versiones

Un caso estructurado se puede clonar, ajustar y volver a ejecutar.
Trazabilidad

Cada caso se vincula a un endpoint, requisito o contrato.
Automatización más sencilla

Un caso claro se puede convertir en una prueba automatizada. Un caso ambiguo debe reescribirse antes de que una herramienta pueda ejecutarlo.

Anatomía de un caso de prueba de API sólido

Una plantilla útil debería incluir estos campos:

Campo	Propósito
ID del caso de prueba	Referencia única, por ejemplo `AUTH-LOGIN-001`
Título	Descripción breve del comportamiento bajo prueba
Endpoint	Método y ruta, por ejemplo `POST /auth/login`
Precondiciones	Estado requerido antes de ejecutar la prueba
Headers	Encabezados requeridos para la solicitud
Cuerpo de la solicitud / parámetros	Payload exacto enviado al endpoint
Estado esperado	Código HTTP esperado
Respuesta esperada	Campos, esquema o valores que deben validarse
Tiempo de respuesta esperado	Presupuesto máximo de latencia
Prioridad	Crítica, alta, media o baja
Tipo de prueba	Funcional, negativa, seguridad, rendimiento o contrato

Los campos que más se omiten suelen ser:

respuesta esperada,
tiempo de respuesta esperado.

Omitirlos permite que una prueba “pase” aunque devuelva un 200 con un cuerpo vacío, o una respuesta correcta pero tres segundos tarde.

Cómo escribir casos de prueba de API paso a paso

1. Lee la documentación de la API

Antes de escribir pruebas, identifica:

método HTTP,
ruta,
headers requeridos,
autenticación,
parámetros obligatorios,
códigos de estado documentados,
esquema de respuesta.

Cada caso de prueba debe validar un comportamiento esperado del contrato.

Si trabajas con OpenAPI, puedes usar herramientas que generen una base inicial desde la especificación. Por ejemplo, una especificación OpenAPI para generar colecciones de prueba puede acelerar el primer borrador.

2. Lista las condiciones que debes probar

Para un endpoint típico, crea casos para:

entrada válida,
cada campo requerido faltante,
cada campo malformado,
solicitud sin autenticación,
token caducado,
payload demasiado grande,
entradas potencialmente peligrosas.

Cada condición debe convertirse en un caso separado.

3. Prepara datos de prueba específicos

No reutilices el mismo payload inválido en todos los casos negativos.

Ejemplo incorrecto:

{
  "email": "",
  "password": ""
}

Ese payload mezcla dos errores. Si la API responde 400, no sabes si falló por email, por password o por ambos.

Mejor:

{
  "email": "dana@example.com"
}

Este caso prueba únicamente la ausencia de password.

4. Escribe resultados esperados verificables

Evita afirmaciones vagas como:

Devuelve éxito.

Escribe algo ejecutable:

Estado esperado: 200
Respuesta esperada:
- token existe
- token es string
- token no está vacío
- token_type es "Bearer"
- expires_in es 3600
Tiempo máximo: 800 ms

La precisión es lo que convierte una intención en una prueba real.

5. Agrega el caso a una suite ejecutable

Un caso en una hoja de cálculo documenta intención. Un caso en una herramienta de pruebas produce un resultado: aprobado o fallido.

Agrupa los casos por endpoint o flujo. Las suites de prueba sirven precisamente para ejecutar conjuntos completos con un solo disparador.

6. Mantén los casos sincronizados con la API

Cuando cambia el contrato, deben cambiar los casos.

Un caso obsoleto es peor que ningún caso porque falla por la razón equivocada y acostumbra al equipo a ignorar builds en rojo.

Ejemplo práctico: probando un endpoint de inicio de sesión

Supongamos este endpoint:

POST /auth/login
Content-Type: application/json

Recibe:

{
  "email": "dana@example.com",
  "password": "Correct-Horse-9"
}

Y devuelve un JWT si las credenciales son válidas.

AUTH-LOGIN-001: credenciales válidas

Tipo: funcional

Prioridad: crítica

POST /auth/login
Content-Type: application/json

Payload:

{
  "email": "dana@example.com",
  "password": "Correct-Horse-9"
}

Validaciones esperadas:

Status: 200
Body:
- token existe
- token es string
- token no está vacío
- token_type == "Bearer"
- expires_in == 3600
Tiempo de respuesta < 800 ms

AUTH-LOGIN-002: contraseña incorrecta

Tipo: negativa

Prioridad: crítica

Payload:

{
  "email": "dana@example.com",
  "password": "wrong"
}

Validaciones esperadas:

Status: 401
Body:
- error == "invalid_credentials"
- token no existe

Nota de seguridad:

El mensaje no debe revelar si el email existe.

AUTH-LOGIN-003: campo `password` faltante

Tipo: negativa

Prioridad: alta

Payload:

{
  "email": "dana@example.com"
}

Validaciones esperadas:

Status: 400
Body:
- error == "validation_error"
- details menciona el campo "password"

AUTH-LOGIN-004: email malformado

Tipo: negativa

Prioridad: media

Payload:

{
  "email": "not-an-email",
  "password": "Correct-Horse-9"
}

Validaciones esperadas:

Status: 400
Body:
- error == "validation_error"

Con estos cuatro casos ya validas:

camino feliz,
errores de autenticación,
validación de campos requeridos,
validación de formato,
forma del error,
códigos de estado,
latencia.

También podrías agregar un caso de seguridad con una cadena de inyección SQL en email.

Ejemplo:

{
  "email": "' OR '1'='1",
  "password": "Correct-Horse-9"
}

Validación esperada:

Status: 400 o 401, según el contrato
Body:
- no expone detalles internos
- no devuelve token

Escribiendo el mismo caso de prueba en Apidog

Puedes implementar los casos anteriores en Apidog sin escribir una línea de script.

1. Importa o define el endpoint

Carga POST /auth/login desde:

un archivo OpenAPI,
una colección de Postman,
una definición manual.

El esquema de solicitud y respuesta sirve como base para las validaciones.

2. Agrega los datos de la solicitud

Para AUTH-LOGIN-001, configura el body:

{
  "email": "dana@example.com",
  "password": "Correct-Horse-9"
}

Para casos repetitivos, puedes usar datos externos en CSV o JSON. Así, las pruebas de API basadas en datos permiten ejecutar el mismo caso contra varias filas de credenciales.

3. Configura las afirmaciones visualmente

Agrega validaciones como:

status == 200
body.token existe
body.token no está vacío
body.token_type == "Bearer"
body.expires_in == 3600
response_time < 800 ms

No necesitas scripting para este flujo.

4. Agrupa los casos en un escenario

Incluye:

AUTH-LOGIN-001
AUTH-LOGIN-002
AUTH-LOGIN-003
AUTH-LOGIN-004

Así puedes ejecutar toda la cobertura del endpoint de login en una sola corrida.

5. Ejecuta y revisa el reporte

Apidog muestra:

casos aprobados,
casos fallidos,
afirmación exacta que falló,
respuesta real recibida.

Puedes ejecutar el escenario:

localmente,
de forma programada,
dentro de CI.

El objetivo no es evitar siempre el código. El objetivo es que los casos simples y repetitivos sean más rápidos de crear, revisar y mantener. Cuando necesitas lógica personalizada, Apidog también permite usar scripts.

Si quieres un flujo más amplio sin depender de Postman, revisa las pruebas de API sin Postman.

Errores comunes a evitar

Afirmar solo el código de estado

Un 200 solo indica que la solicitud fue procesada. No garantiza que la respuesta sea correcta.

Valida siempre el cuerpo:

status == 200
body.data.id existe
body.data.email == "dana@example.com"

Crear un caso gigante por endpoint

Si un único caso valida login correcto, contraseña incorrecta, email inválido y token caducado, cuando falle no sabrás qué se rompió.

Divide por condición.

Reutilizar los mismos datos negativos

Cada caso negativo debe fallar por una razón específica.

Mal:

{
  "email": "",
  "password": ""
}

Mejor:

{
  "email": "dana@example.com"
}

No validar latencia

Sin una afirmación de tiempo, una regresión de rendimiento puede pasar inadvertida.

Ejemplo:

response_time < 800 ms

Documentar casos que nunca se ejecutan

Un caso que nadie ejecuta es documentación, no una prueba.

Muévelo a una suite automática y ejecútalo en cada build. Una forma rápida de empezar es generar scripts de prueba a partir de una especificación OpenAPI.

Descarga Apidog si quieres seguir el ejemplo y construir los cuatro casos de inicio de sesión por tu cuenta.

Preguntas frecuentes

¿Cuántos casos de prueba necesita un endpoint?

Los suficientes para cubrir:

camino feliz,
campos requeridos faltantes,
entradas malformadas,
falla de autenticación,
al menos una prueba de seguridad,
contrato de respuesta.

Para un endpoint simple suelen ser entre cuatro y seis casos. Para endpoints complejos, más.

¿Debo escribir casos antes de construir la API?

Sí. Escribir casos contra el diseño ayuda a detectar deficiencias del contrato antes de implementar.

Puedes combinar un enfoque design-first con generación de casos de prueba asistida por IA para obtener un primer borrador y luego refinarlo manualmente.

¿Hoja de cálculo o herramienta de prueba?

Una hoja de cálculo sirve para documentar, pero no ejecuta.

Mantén los casos en una herramienta que pueda:

ejecutar pruebas,
reportar resultados,
mostrar fallos,
integrarse con CI.

Un caso debe estar en verde o en rojo, no solo escrito.

¿Cuál es la diferencia entre un caso de prueba y un escenario de prueba?

Un escenario es el objetivo de alto nivel:

Verificar inicio de sesión.

Un caso es una validación concreta y ejecutable:

Enviar credenciales válidas a POST /auth/login y confirmar status 200, token JWT y latencia menor a 800 ms.

Consulta escenario de prueba vs caso de prueba para ver la diferencia con más detalle.

Mejores Depuradores Agent2Agent (A2A) en 2026

Roobia — Fri, 22 May 2026 07:21:06 +0000

Agent2Agent (A2A) ya está pasando de la especificación a implementaciones reales. En cuanto ejecutas un segundo agente, necesitas inspeccionar qué se envían entre sí: Tarjetas de Agente, mensajes JSON-RPC, archivos, metadatos, respuestas y errores. Esta guía compara las herramientas disponibles hoy y te ayuda a elegir cuál usar según tu flujo de trabajo.

Prueba Apidog hoy

Si A2A es nuevo para ti, empieza por qué es Agent2Agent (A2A) y qué es un depurador A2A. Ahí se explican la Tarjeta de Agente, el ciclo de vida de las tareas y por qué el tráfico agente-a-agente requiere herramientas específicas.

Cómo evaluar un depurador A2A

Antes de elegir una herramienta, valida que cubra este flujo mínimo:

Descubrir el agente
- Leer la URL de la Tarjeta de Agente.
- Validar que la tarjeta sea compatible.
- Mostrar nombre, descripción, capacidades, habilidades y versión del protocolo.
Enviar mensajes de prueba
- Enviar texto sin construir JSON-RPC manualmente.
- Adjuntar archivos cuando el agente los soporte.
- Añadir metadatos como pares clave-valor.
Inspeccionar respuestas
- Ver una respuesta legible.
- Revisar el contenido devuelto al usuario.
- Acceder al JSON-RPC sin procesar para depuración profunda.
Configurar autenticación
- Usar Bearer token, Basic Auth, API key o encabezados personalizados.
- Probar agentes detrás de gateways, proxies o routing multi-tenant.

También conviene comprobar si soporta streaming, historial de sesiones y ejecución local para evitar enrutar tráfico sensible por terceros.

1. Depurador A2A de Apidog

Apidog incluye un Depurador A2A dentro de su cliente estándar. Es la opción más completa para equipos que necesitan depurar agentes A2A de forma visual.

Flujo básico de uso

Abre el Depurador A2A en Apidog.
Pega la URL de la Tarjeta de Agente.
Haz clic en Conectar.
Revisa la información detectada:
- nombre del agente;
- descripción;
- capacidades;
- habilidades declaradas;
- versión del protocolo.
Abre la pestaña Mensajes.
Envía un mensaje de texto plano.
Si el agente lo permite, adjunta archivos.
Añade metadatos personalizados si tu flujo los requiere.
Revisa la respuesta en las vistas disponibles.

Apidog muestra las respuestas en tres niveles:

Vista previa: árbol legible para inspección rápida.
Contenido: cuerpo legible por humanos.
Datos sin procesar: payload JSON-RPC completo.

La autenticación se configura desde la interfaz: sin auth, Bearer token, Basic Auth o API key mediante encabezado personalizado. También puedes añadir headers propios para gateways, tenants o reglas de routing.

Cuando el agente soporta server-sent events, Apidog permite probar streaming. Además, guarda el historial de la sesión y se ejecuta como cliente local, por lo que el tráfico va directamente entre tu máquina y el agente.

Cuándo usarlo

Usa Apidog cuando necesitas:

depurar interactivamente un agente A2A;
validar rápidamente una Tarjeta de Agente;
probar mensajes con archivos y metadatos;
inspeccionar respuestas legibles y JSON sin procesar;
trabajar en el mismo entorno con REST, GraphQL, MCP y A2A.

Fortalezas: amplia cobertura funcional, sin scripting, tres vistas de respuesta, autenticación en UI y soporte para otros protocolos usados en sistemas de agentes.

Desventaja: forma parte del cliente completo de Apidog. Si solo quieres una CLI mínima, puede ser más de lo necesario.

Ideal para: equipos que desarrollan o consumen agentes A2A y quieren un flujo visual sin escribir scripts.

Para empezar, sigue la guía del depurador A2A de Apidog y descarga Apidog.

2. Inspector A2A

El proyecto A2A mantiene un Inspector A2A de código abierto. Es una herramienta web para conectarte a un agente, ver su Tarjeta de Agente y probar mensajes. Está publicada junto con la especificación en la organización A2A de GitHub.

Al venir del mismo proyecto que mantiene el protocolo, es útil como referencia de conformidad. Puedes usarlo para comprobar si una Tarjeta de Agente y un intercambio A2A siguen lo esperado por la especificación.

Flujo recomendado

Ejecuta el Inspector localmente.
Conéctalo a tu agente A2A.
Carga la Tarjeta de Agente.
Verifica que la estructura sea válida.
Envía un mensaje básico.
Compara la respuesta con lo esperado por la especificación.

Fortalezas: alineado con la especificación, código abierto, gratuito y útil como referencia técnica.

Desventaja: normalmente debes ejecutarlo tú mismo. La experiencia de usuario, la autenticación y el manejo de archivos son más limitados que en una herramienta dedicada.

Ideal para: desarrolladores que quieren una implementación de referencia y no tienen problema en ejecutarla localmente.

3. Herramientas CLI y SDK de A2A

Los SDK oficiales de A2A, incluidos Python y JavaScript/TypeScript, ofrecen clientes de ejemplo y utilidades de línea de comandos. Puedes usarlos para obtener una Tarjeta de Agente, enviar mensajes e imprimir respuestas desde la terminal.

Este enfoque es útil cuando necesitas automatización.

Casos de uso prácticos

Usa la CLI o el SDK para:

pruebas de humo en CI;
validaciones de conformidad;
comprobaciones periódicas de agentes desplegados;
scripts de regresión;
pruebas rápidas sin interfaz gráfica.

Un flujo típico sería:

# Pseudoflujo orientativo
a2a get-card https://tu-agente.example.com/.well-known/agent-card.json

a2a send-message \
  --agent https://tu-agente.example.com \
  --message "Resume este documento"

Después puedes integrar la salida en tu pipeline:

# Ejemplo conceptual
a2a send-message \
  --agent "$A2A_AGENT_URL" \
  --message "ping" \
  --expect-status success

Fortalezas: programable, automatizable y fácil de integrar en CI si ya usas el SDK.

Desventaja: no ofrece vistas visuales, diff, historial interactivo ni renderizado cómodo de respuestas. Para depuración exploratoria, leer JSON sin procesar en terminal se vuelve lento.

Ideal para: CI, automatización y pruebas de conformidad; no para depuración interactiva diaria.

4. Agentes de ejemplo y UI de demostración de A2A

El proyecto A2A publica agentes de ejemplo y una interfaz de demostración multiagente en su repositorio de muestras, accesible desde el sitio del protocolo A2A.

La UI de demostración permite observar cómo varios agentes coordinan tareas y qué mensajes intercambian.

Cómo aprovecharla

Ejecuta la demo oficial.
Observa un flujo multiagente completo.
Identifica cómo se ve una Tarjeta de Agente válida.
Revisa cómo se encadenan los mensajes.
Usa ese comportamiento como referencia al depurar tu propio agente.

Esta herramienta está pensada para enseñar el protocolo, no para depurar agentes arbitrarios en producción.

Fortalezas: buena para aprender, muestra flujos multiagente reales, gratuita y de código abierto.

Desventaja: es una demo. No ofrece el mismo control sobre agentes propios que un depurador como Apidog o el Inspector.

Ideal para: aprender el protocolo y ver un intercambio A2A saludable antes de depurar tu implementación.

5. Clientes API generales: curl y scripts personalizados

Antes de usar herramientas dedicadas, muchos equipos prueban A2A con curl o scripts desechables. Técnicamente funciona porque A2A usa JSON-RPC sobre HTTP.

Un ejemplo conceptual sería:

curl -X POST https://tu-agente.example.com \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "id": "test-1",
    "method": "message/send",
    "params": {
      "message": {
        "role": "user",
        "parts": [
          {
            "kind": "text",
            "text": "Hola, agente"
          }
        ]
      }
    }
  }'

Esto sirve para una verificación puntual, pero escala mal. Tienes que construir manualmente el sobre JSON-RPC, gestionar autenticación, revisar payloads anidados y actualizar el script cada vez que cambia la Tarjeta de Agente.

Fortalezas: disponible en cualquier entorno y útil para una prueba rápida.

Desventaja: sin validación de Tarjeta de Agente, sin renderizado de respuestas, sin historial, sin UI de autenticación y sin soporte cómodo de streaming.

Ideal para: una comprobación puntual, no para depuración continua.

Comparación rápida

Herramienta	Tipo	Vistas de respuesta visuales	Autenticación en UI	Streaming	Ideal para
Depurador A2A de Apidog	Cliente visual	Tres vistas	Sí	Sí	Depuración A2A diaria
Inspector A2A	Herramienta web autoejecutable	Básico	Limitado	Parcial	Referencia de especificación
CLI / SDK de A2A	Línea de comandos	Ninguna, JSON sin procesar	Vía parámetros	Limitado	CI y automatización
UI de demostración de A2A	Aplicación de ejemplo	Integrado	N/A	Sí	Aprender el protocolo
curl / scripts	HTTP sin procesar	Ninguna	Manual	No	Verificaciones puntuales

¿Cuál deberías usar?

Para depuración interactiva diaria, el Depurador A2A de Apidog es la opción práctica. Valida Tarjetas de Agente, envía mensajes con archivos y metadatos, muestra respuestas en tres vistas y configura autenticación sin scripts.

Si trabajas con sistemas de agentes que combinan protocolos, tener REST, GraphQL, MCP y A2A en una misma herramienta evita saltar entre clientes. La guía del servidor MCP vs A2A explica por qué esa combinación importa a medida que crece la arquitectura.

Para conformidad automatizada, combina Apidog con la CLI del SDK de A2A:

Depura visualmente el error.
Corrige el comportamiento del agente.
Convierte el caso en una prueba automatizada.
Ejecútala en CI.

La misma disciplina descrita en cómo probar agentes de IA que llaman a tus APIs aplica aquí: primero confirma la comunicación, después automatiza la regresión.

Para aprender el protocolo, ejecuta la UI de demostración de A2A y observa un flujo multiagente funcional. Después pasa a un depurador real para probar tus propios agentes.

Cuando tus agentes empiecen a usar credenciales, revisa la guía de credenciales seguras de API para agentes de IA para definir rotación, alcance y manejo seguro.

Resumen práctico:

Usa Apidog para encontrar errores rápido.
Usa Inspector A2A para contrastar con la especificación.
Usa CLI / SDK para automatizar validaciones.
Usa demos oficiales para aprender.
Usa curl solo para comprobaciones puntuales.

Preguntas frecuentes

¿Cuál es el mejor depurador A2A en este momento?

Para depuración interactiva, el Depurador A2A de Apidog es el más completo: valida Tarjetas de Agente, prueba mensajes con archivos y metadatos, ofrece tres vistas de respuesta, configura autenticación y soporta streaming sin escribir scripts.

¿Existen depuradores A2A gratuitos?

Sí. El Depurador A2A de Apidog se incluye de forma gratuita con el cliente estándar. El Inspector A2A oficial, la CLI del SDK y la UI de demostración también son gratuitos y de código abierto.

¿Puedo depurar agentes A2A con Postman?

Puedes enviar manualmente una solicitud HTTP JSON-RPC, pero Postman no tiene soporte A2A nativo. Eso significa que pierdes validación de Tarjeta de Agente, renderizado especializado de respuestas y soporte de streaming orientado al protocolo. Un depurador A2A dedicado maneja esa capa por ti.

¿Funcionan los depuradores A2A con cualquier framework de agente?

Sí, siempre que el agente publique una Tarjeta de Agente A2A válida. A2A es agnóstico al framework, por lo que puede funcionar con LangGraph, CrewAI, AutoGen y agentes personalizados. Para los conceptos base, consulta qué es Agent2Agent (A2A).

¿Debería usar una CLI o un depurador A2A visual?

Usa ambos. Un depurador visual como Apidog es más rápido para aislar errores. Una CLI es mejor para automatizar verificaciones en CI. El flujo recomendado es depurar visualmente y luego convertir el caso corregido en una prueba programable.

¿Cómo empiezo a depurar un agente A2A?

Descarga Apidog, abre el Depurador A2A, pega la URL de la Tarjeta de Agente, haz clic en Conectar y envía un mensaje de texto plano. La guía del Depurador A2A de Apidog cubre el flujo completo.

¿Qué es un Depurador Agente2Agente (A2A) y Por Qué lo Necesitas?

Roobia — Fri, 22 May 2026 07:18:48 +0000

Construiste un agente A2A. Se conecta, funciona y a veces devuelve algo incorrecto. ¿Y ahora qué? Abres la consola y ves un flujo de envolturas JSON-RPC con los campos importantes enterrados varios niveles dentro del payload. No puedes saber si el fallo está en el transporte, en la autenticación, en el formato del mensaje o en la lógica del agente. Esa es la brecha que cubre un depurador Agent2Agent A2A.

Prueba Apidog hoy

Este artículo explica qué es un depurador A2A, por qué depurar tráfico agente-a-agente es difícil sin uno, qué debe hacer una buena herramienta y cómo usarla en un ciclo de depuración práctico. Si primero necesitas contexto del protocolo, empieza con qué es Agent2Agent A2A.

¿Qué es un depurador A2A?

Un depurador A2A es una herramienta que te permite conectarte a un agente Agent2Agent, enviar mensajes de prueba e inspeccionar la solicitud y la respuesta completas sin escribir código de cliente.

Funciona de forma parecida a un cliente REST para APIs:

Pegas la URL de la Tarjeta de Agente.
El depurador descubre las capacidades del agente.
Envías un mensaje de prueba.
Inspeccionas el payload A2A y la envoltura JSON-RPC.
Identificas el campo, encabezado, artefacto o metadata que está fallando.

A2A es el protocolo abierto para la comunicación entre agentes de IA. Define la Tarjeta de Agente, el ciclo de vida de la tarea y el formato de mensajes y artefactos que intercambian los agentes. Un depurador A2A es el banco de pruebas para validar todo eso manualmente antes de integrarlo en un flujo de producción.

La pregunta que debe responder es concreta:

Dada esta Tarjeta de Agente, ¿qué hace realmente el agente cuando le envío este mensaje?

Por qué depurar A2A es difícil sin uno

El tráfico agente-a-agente suele quedar oculto detrás de SDKs, abstracciones y payloads anidados.

Los logs de consola omiten datos críticos

Un SDK de agente registra lo que sus autores decidieron registrar. Puede que veas algo como:

Task completed

Pero no necesariamente verás:

taskId
partes del mensaje
artefactos generados
metadatos por mensaje
errores JSON-RPC
referencias a archivos
estado real de la tarea

Si el campo defectuoso no se imprime en stdout, los logs no bastan.

La pestaña de red no entiende A2A

El panel de red del navegador muestra cuerpos HTTP, pero A2A usa estructuras JSON-RPC anidadas. Puedes terminar inspeccionando algo como esto:

{
  "jsonrpc": "2.0",
  "id": "req-1",
  "result": {
    "task": {
      "id": "task-123",
      "status": {
        "state": "completed"
      },
      "artifacts": [
        {
          "parts": [
            {
              "kind": "text",
              "text": "Resultado generado por el agente"
            }
          ]
        }
      ]
    }
  }
}

El dato importante puede estar varios niveles dentro de result.task.artifacts[].parts[].

Los scripts temporales se rompen rápido

La alternativa habitual es escribir un curl, un script en Python o un cliente desechable.

Ejemplo:

curl -X POST http://localhost:3000/a2a \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "test-1",
    "method": "message/send",
    "params": {
      "message": {
        "parts": [
          {
            "kind": "text",
            "text": "Resume este documento"
          }
        ]
      }
    }
  }'

Funciona un día. Luego cambia la Tarjeta de Agente, cambia la autenticación o se añade metadata obligatoria, y el script queda desactualizado.

Los errores de transporte y lógica se ven iguales

Cuando un agente devuelve una respuesta incorrecta, la causa puede ser:

una solicitud mal formada
una conexión rota
un fallo de autenticación
un encabezado faltante
metadata enviada en el lugar equivocado
razonamiento incorrecto del modelo
lógica defectuosa del agente

Sin ver la conexión completa, todo se resume en “el agente está roto”.

Un depurador A2A reduce esa ambigüedad: ves exactamente qué enviaste, qué recibió el agente y qué respondió.

Qué hace un depurador A2A

Un depurador A2A útil debe cubrir cuatro áreas: descubrimiento, pruebas de mensajes, inspección de respuestas y autenticación.

1. Conexión y descubrimiento

El primer paso es conectarte a la Tarjeta de Agente.

En desarrollo local, una URL típica puede ser:

http://localhost:3000/.well-known/agent.json

El depurador debe obtener esa tarjeta, validarla y mostrar información como:

nombre del agente
descripción
versión del protocolo
capacidades anunciadas
habilidades declaradas
tipos de entrada soportados
endpoints disponibles

Si la tarjeta está mal formada, la herramienta debe fallar de forma explícita y señalar el campo problemático.

Ejemplo de diagnóstico útil:

Agent Card validation failed:
missing required field: capabilities

Eso es mucho mejor que un error genérico como:

Connection failed

2. Pruebas de mensajes

Una vez conectado, deberías poder enviar mensajes sin construir manualmente el JSON-RPC.

El flujo práctico debería ser:

Escribir un prompt.
Añadir archivos si el agente los soporta.
Añadir metadata por mensaje si aplica.
Configurar autenticación o encabezados.
Enviar.
Revisar la respuesta.

Ejemplo de mensaje mínimo:

Resume el contenido del archivo adjunto en tres puntos.

Ejemplo de metadata que podrías enviar junto al mensaje:

{
  "tenantId": "acme",
  "traceId": "debug-run-001",
  "priority": "low"
}

El depurador debe encargarse de envolver esa entrada en la estructura A2A correcta y en JSON-RPC. Tú no deberías tener que escribir el cliente desde cero para cada prueba.

3. Inspección de respuestas

Este es el valor principal.

Las respuestas A2A pueden incluir:

texto plano
artefactos estructurados
referencias a archivos
partes múltiples
errores JSON-RPC
estados de tarea
respuestas parciales en streaming

Un buen depurador debe mostrar el mismo resultado desde varios ángulos.

El depurador A2A de Apidog, por ejemplo, ofrece tres vistas:

Vista previa: renderiza campos estructurados como un árbol legible.
Contenido: muestra el cuerpo legible para humanos.
Datos sin procesar: muestra el payload JSON-RPC completo.

Esto permite diagnosticar rápido casos como:

Síntoma	Diagnóstico probable
La Vista previa tiene datos, pero Contenido está vacío	El agente devolvió un artefacto estructurado que no se puede aplanar como texto
Contenido muestra texto, pero faltan metadatos	El agente generó salida, pero no adjuntó contexto esperado
Datos sin procesar muestra error JSON-RPC	El fallo está antes de la lógica final del agente
La respuesta está bien formada, pero semánticamente incorrecta	El problema probablemente está en el prompt, herramientas o razonamiento del agente

Sin esas vistas, el diagnóstico puede convertirse en una revisión manual larga de JSON anidado.

4. Autenticación y encabezados

Los agentes de producción rara vez están abiertos. Suelen estar detrás de:

Bearer Token
Autenticación Básica
clave de API
encabezados personalizados
gateways internos
proxies reversos
identificadores de tenant

Un depurador A2A debe permitir configurar esos valores desde la interfaz.

Ejemplo de encabezados:

Authorization: Bearer <token>
X-Tenant-ID: acme
X-Request-ID: debug-001

También debe diferenciar claramente entre:

Encabezados HTTP: llegan a gateways, proxies y middleware.
Metadatos A2A: llegan al manejador de tareas del agente.

Este error es común:

X-User-Intent: summarize

Si el agente espera esa información dentro de metadata A2A y no en un encabezado HTTP, nunca la leerá.

El Depurador A2A de Apidog

Apidog incluye un Depurador A2A dentro de su cliente estándar.

El flujo básico es:

Abre el Depurador A2A.
Pega la URL de la Tarjeta de Agente.
Haz clic en Conectar.
Revisa los metadatos del agente.
Abre la pestaña Mensajes.
Escribe un prompt.
Opcionalmente adjunta un archivo o añade metadata.
Haz clic en Enviar.
Revisa la respuesta en Vista previa, Contenido y Datos sin procesar.

Para desarrollo local, puedes probar con una URL como:

http://localhost:3000/.well-known/agent.json

Apidog maneja:

envoltura JSON-RPC
análisis de respuestas
historial de sesión
archivos adjuntos
metadata
encabezados personalizados
streaming con eventos enviados por el servidor cuando el agente lo soporta

El historial de sesión permite repetir pruebas y comparar respuestas sin reconstruir cada mensaje.

También cubre una diferencia importante: encabezados HTTP frente a metadata A2A. Ver ambos canales lado a lado ayuda a detectar errores como enviar contexto de tarea en un encabezado que el agente nunca lee.

Para una guía paso a paso completa, consulta la guía del Depurador A2A de Apidog. Apidog también tiene un depurador de agentes de IA para el flujo más amplio de pruebas de agentes.

Qué buscar en un depurador A2A

Cuando compares herramientas, usa esta lista.

Validación clara de la Tarjeta de Agente

Debe decirte por qué falla una tarjeta, no solo que falló.

Bueno:

missing required field: skills[0].name

Malo:

invalid agent card

Múltiples vistas de respuesta

Necesitas al menos:

una vista legible
una vista estructurada
el JSON sin procesar

Solo ver JSON bruto no es suficiente cuando trabajas con artefactos, partes y tareas.

Cobertura de autenticación

Debe soportar:

Bearer Token
Basic Auth
API Key
encabezados personalizados

Sin tener que codificar base64 manualmente ni modificar scripts.

Archivos y metadata

El tráfico A2A real no siempre es texto. Un depurador solo de texto deja fuera una parte importante de la superficie de prueba.

Busca soporte para:

archivos adjuntos
metadata por mensaje
tipos de entrada declarados por el agente
artefactos estructurados en la respuesta

Soporte de streaming

Si el agente usa eventos enviados por el servidor, el depurador debe mostrar fragmentos a medida que llegan y luego mostrar el payload ensamblado al cerrar la transmisión.

Historial de sesión

Durante la depuración enviarás variaciones del mismo mensaje muchas veces. El historial ayuda a:

repetir pruebas
comparar respuestas
volver a una ejecución anterior
aislar cuándo cambió el comportamiento

Tráfico local o directo

Para desarrollo y debugging, es importante que la herramienta pueda comunicarse directamente con tu agente, sin redirigir tus payloads por servidores de terceros.

Un depurador que cubre estos puntos convierte la depuración A2A en una rutina de verificación, no en una suposición. La misma disciplina que se aplica en cómo probar agentes de IA que llaman a tus APIs también aplica a la capa A2A. Si además ejecutas servidores MCP, la guía servidor MCP vs A2A explica por qué a menudo necesitas un depurador para cada protocolo.

Un ciclo de depuración práctico

Cuando un agente A2A se comporta mal, usa este ciclo.

1. Verifica la Tarjeta de Agente

Conéctate al agente y confirma que la tarjeta anuncia la habilidad esperada.

Comprueba:

nombre correcto
versión correcta
endpoint correcto
habilidad esperada
tipos de entrada soportados
capacidades necesarias

Si la habilidad no aparece en la tarjeta, no empieces por el prompt. Arregla primero el manifiesto.

2. Envía el mensaje mínimo

Empieza con texto plano.

Hola, responde con "ok".

Luego prueba la habilidad real:

Resume este texto en una frase: Agent2Agent permite comunicación entre agentes.

Añade archivos y metadata solo cuando el caso mínimo funcione.

3. Lee primero los datos sin procesar

Antes de mirar la vista bonita, revisa el JSON-RPC completo.

Busca:

id
result
error
task
status
artifacts
parts
campos de metadata

Si el campo esperado no existe en el payload bruto, el problema está en el agente o en la solicitud, no en el renderizador.

4. Separa transporte de lógica

Usa esta regla:

Resultado	Conclusión
No conecta	problema de URL, red, TLS, gateway o autenticación
Conecta, pero falla JSON-RPC	problema de formato, método o payload
Responde bien formado, pero con datos faltantes	problema de implementación del agente
Responde bien formado, pero semánticamente mal	problema de prompt, herramientas, modelo o lógica
Funciona sin metadata, falla con metadata	problema en el canal de metadata o parsing del agente
Funciona sin archivo, falla con archivo	problema en adjuntos o tipo de entrada

5. Repite con una sola variable por prueba

No cambies prompt, metadata, archivos y encabezados al mismo tiempo.

Orden recomendado:

Texto mínimo.
Texto real.
Metadata.
Archivo.
Autenticación real.
Streaming.
Caso completo.

Así puedes identificar qué cambio introduce el fallo.

Preguntas frecuentes

¿Qué es un depurador A2A en una frase?

Es una herramienta que se conecta a un agente Agent2Agent, le envía mensajes de prueba y muestra la solicitud y respuesta completas para depurar integraciones de agentes sin escribir código de cliente.

¿En qué se diferencia un depurador A2A de un cliente API?

Un cliente API prueba endpoints HTTP. Un depurador A2A entiende la capa Agent2Agent: Tarjetas de Agente, ciclo de vida de tareas, partes de mensajes y artefactos. Analiza y renderiza esas estructuras en lugar de mostrar solo un cuerpo HTTP en bruto.

¿Necesito un depurador A2A si tengo logs?

Sí, si necesitas ver el tráfico real. Los logs muestran lo que el autor del agente decidió registrar. Un depurador muestra la solicitud y respuesta completas, lo que permite distinguir errores de transporte de errores de lógica. Para contexto del protocolo, consulta qué es Agent2Agent A2A.

¿Es gratuito el Depurador A2A de Apidog?

Sí. Viene incluido con el cliente estándar de Apidog. Descarga Apidog y el Depurador A2A aparecerá en el panel lateral en una versión reciente.

¿Puede un depurador A2A probar agentes en cualquier framework?

Sí, siempre que el agente exponga una Tarjeta de Agente A2A válida. El protocolo es agnóstico al framework, por lo que puede usarse con agentes implementados en LangGraph, CrewAI, AutoGen o frameworks personalizados.

¿Maneja un depurador A2A respuestas de streaming?

Uno bueno sí. Cuando el agente soporta eventos enviados por el servidor, el depurador lee los fragmentos a medida que llegan, actualiza sus vistas en tiempo real y muestra el payload ensamblado cuando la transmisión termina.

DEV Community: Roobia

Cómo Usar Insomnia para Probar una API

Instalar Insomnia y crear una solicitud

Configurar métodos, parámetros y autenticación

Enviar un cuerpo JSON

Añadir parámetros de consulta

Añadir encabezados

Configurar autenticación

Configurar entornos y variables

Encadenar solicitudes con etiquetas de plantilla

Escribir suites de pruebas con aserciones

Organizar suites de pruebas

Ejecutar pruebas desde la línea de comandos con Inso

El cambio a la nube en Insomnia 8 y una alternativa

Preguntas frecuentes

¿Es Insomnia gratuito?

¿Qué protocolos soporta Insomnia?

¿Cómo escribo aserciones en Insomnia?

¿Qué cambió en Insomnia 8?

¿Puedo ejecutar pruebas de Insomnia en una pipeline de CI?

Cómo Simular una API para Pruebas: Guía Práctica

Cuándo simular la API

Flujo de trabajo en cinco pasos

Paso 1: Define el esquema

Paso 2: Genera respuestas simuladas

Respuestas estáticas

Respuestas dinámicas

Paso 3: Ejecuta el servidor de simulación

Opción A: servidor mock local

Opción B: servidor mock en la nube

Paso 4: Apunta tus pruebas al mock

Paso 5: Prueba las rutas de error

Organiza los mocks en una suite creciente

Agrupa por servicio real

Nombra fixtures por escenario

Versiona los mocks junto a los tests

Usa una respuesta base

Mantén la simulación alineada con la API real

1. Genera mocks desde el mismo esquema

2. Ejecuta pruebas de contrato contra la API real

3. Revisa mocks en cada pull request

Preguntas frecuentes

¿Debería simular la API para cada prueba?

¿Cuál es la diferencia entre una respuesta mock estática y dinámica?

¿Cómo aseguro que mi mock siga siendo preciso?

¿Puede un mock simular respuestas lentas o fallidas?

¿Servidor mock local o en la nube?

Cómo Probar APIs con Postman: Guía Práctica Paso a Paso

Configure Postman y envíe su primera solicitud

Organice las solicitudes en colecciones

Escriba pruebas en la pestaña Pruebas

Use entornos y variables

Ejecute una colección completa con el Collection Runner

Pruebas basadas en datos

Donde Postman se vuelve pesado y qué considerar

Preguntas frecuentes

¿Necesito escribir código para probar APIs en Postman?

¿Cuál es la diferencia entre una colección de Postman y un entorno?

¿Cómo ejecuto las pruebas de Postman automáticamente en CI?

¿Puede Postman probar más que APIs REST?

¿Cuántas aserciones debería tener una solicitud?

Cómo usar Assert en Node.js: Guía práctica

Qué hace el módulo assert

Usa modo estricto, no modo legado

Comparar valores primitivos con strictEqual

Comparar objetos y arrays con deepStrictEqual

Validar existencia y formato con ok y match

Probar que una función lanza errores con throws

Probar promesas rechazadas con rejects

Usar assert para probar respuestas de API

Preguntas frecuentes

¿Necesito instalar el módulo assert?

¿Cuál es la diferencia entre assert.equal y assert.strictEqual?

¿Cuándo debo usar deepStrictEqual en lugar de strictEqual?

¿Debo usar assert o un framework como Jest?

¿Cómo afirmo que una función asíncrona se rechaza?

Herramientas Gratuitas Online para Probar APIs: Guía Práctica

Qué significa realmente “gratuito en línea”

Herramientas gratuitas que merece la pena probar

Apidog

Qué hace el módulo `assert`

Comparar valores primitivos con `strictEqual`

Comparar objetos y arrays con `deepStrictEqual`

Validar existencia y formato con `ok` y `match`

Probar que una función lanza errores con `throws`

Probar promesas rechazadas con `rejects`

Usar `assert` para probar respuestas de API

¿Necesito instalar el módulo `assert`?

¿Cuál es la diferencia entre `assert.equal` y `assert.strictEqual`?

¿Cuándo debo usar `deepStrictEqual` en lugar de `strictEqual`?

¿Debo usar `assert` o un framework como Jest?