DEV Community

Cover image for Cómo usar consultas de base de datos en pruebas de API con Apidog (MySQL, MongoDB, Redis)
Roobia
Roobia

Posted on • Originally published at apidog.com

Cómo usar consultas de base de datos en pruebas de API con Apidog (MySQL, MongoDB, Redis)

Un código de estado verde puede mentir. Su endpoint POST /orders devuelve 201 Created, el cuerpo parece correcto y la prueba pasa. Pero ¿la fila realmente llegó a la base de datos con el estado esperado? ¿Se redujo el inventario? Una prueba que solo lee la respuesta HTTP verifica lo que la API dijo, no lo que el sistema hizo. Para cerrar esa brecha, debe consultar la base de datos.

Prueba Apidog hoy

Las consultas a la base de datos dentro de un escenario de prueba permiten sembrar un estado conocido, ejecutar una solicitud HTTP y comprobar directamente los datos persistidos. Apidog incorpora esta capacidad mediante Conexiones de Base de Datos y el procesador Operación de Base de Datos, sin scripts externos. Si está empezando con escenarios, consulte cómo escribir un escenario de prueba con Apidog. Para una introducción a modelos relacionales, revise la descripción general del lado del servidor de MDN.

Qué aportan las operaciones de base de datos a una prueba

Una prueba de API que no consulta la base de datos funciona como una caja negra: confía en la respuesta. Esto puede ser suficiente para muchos casos, pero no detecta discrepancias entre la respuesta y el estado persistido:

  • Un campo status que nunca cambia.
  • Una clave externa inválida.
  • Una eliminación suave que termina borrando el registro.
  • Una caché o inventario que no se actualiza.

Los pasos de base de datos permiten:

  1. Sembrar un estado inicial preciso.
  2. Afirmar contra la fuente de verdad leyendo la fila escrita por la API.
  3. Extraer valores reales de la base de datos para usarlos en solicitudes posteriores.

Apidog separa esta funcionalidad en dos partes:

  1. Cree una conexión reutilizable en Configuración > Conexiones de Base de Datos.
  2. Añada una Operación de Base de Datos a una solicitud como:
    • Preprocesador, antes de la solicitud.
    • Postprocesador, después de la solicitud.

MySQL, SQL Server 2014 o posterior, PostgreSQL y Oracle están disponibles en el plan gratuito. ClickHouse, MongoDB y Redis requieren un plan de pago. El ejemplo principal de este artículo usa MySQL.

Paso 1: crear una conexión a la base de datos

Abra Configuración > Conexiones de Base de Datos y haga clic en + Nuevo. Seleccione el motor y complete los datos:

  • Host, por ejemplo db.staging.internal o 127.0.0.1.
  • Puerto, como 3306 para MySQL.
  • Nombre de usuario y Contraseña.
  • Nombre de la base de datos, por ejemplo shop.

Configuración de conexión de base de datos en Apidog

Si la base de datos está detrás de un bastión, expanda Túnel SSH y configure el host de salto.

Para MySQL, el modo SSL ofrece estas opciones:

  • Prefer: intenta SSL y vuelve a una conexión no SSL si es necesario.
  • Require
  • Verify CA
  • Verify Full

Use la opción más estricta compatible con su servidor y haga clic en Guardar.

Errores habituales de conexión

Autenticación de MySQL 8

El plugin predeterminado caching_sha2_password puede rechazar conexiones. Si recibe un error de autenticación, puede cambiar el usuario:

ALTER USER 'tester'@'%'
IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

Consulte el manual de referencia de MySQL para conocer las diferencias entre plugins.

Las credenciales se guardan localmente

Los detalles de conexión no se sincronizan con la nube. Cada integrante del equipo debe configurar su propia conexión. Para coordinar esta configuración, consulte cómo compartir la configuración de conexión a la base de datos.

Paso 2: sembrar datos con un Preprocesador

Suponga que prueba la creación de pedidos. Antes de crear un pedido, necesita garantizar que existe un cliente activo.

En la solicitud:

  1. Abra Preprocesadores.
  2. Seleccione Agregar Procesador de Base de Datos.
  3. Elija Operación de base de datos.
  4. Asigne un nombre, por ejemplo sembrar cliente.
  5. Seleccione la conexión MySQL.
  6. En Introducir Comando SQL, añada la inserción.
INSERT INTO customers (id, email, status)
VALUES ({{customer_id}}, '{{customer_email}}', 'active')
ON DUPLICATE KEY UPDATE status = 'active';
Enter fullscreen mode Exit fullscreen mode

Las variables dinámicas usan la sintaxis {{nombre_variable}}.

Con este paso, cada ejecución empieza con un cliente conocido. La prueba no depende de datos sobrantes ni del orden de ejecución de otras pruebas.

Paso 3: verificar la persistencia con un Postprocesador

Ahora cree el pedido mediante la API:

POST /api/orders
Content-Type: application/json

{
  "customer_id": {{customer_id}},
  "items": [{ "sku": "APRON-01", "qty": 2 }]
}
Enter fullscreen mode Exit fullscreen mode

Suponga que la respuesta devuelve el ID del pedido y que lo guarda en la variable order_id mediante una aserción de respuesta.

A continuación:

  1. Abra Postprocesadores.
    • En MODO DISEÑO, están en la pestaña Ejecutar.
    • En MODO DEBUG, están en la pestaña Solicitud.
  2. Seleccione Agregar Postprocesador > Operación de base de datos.
  3. Nómbrelo verificar fila de pedido.
  4. Seleccione la conexión.
  5. Configure una consulta SELECT.
SELECT id, status, total_cents
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

Los resultados se devuelven como un array de objetos. Para extraer el estado del primer resultado:

  1. Abra Extraer Resultados (Opcional).
  2. Añada Extraer Resultado a Variable.
  3. Use db_order_status como Nombre de Variable.
  4. Use esta expresión JSONPath:
$[0].status
Enter fullscreen mode Exit fullscreen mode

Ejecute la solicitud y revise la Consola. Después, añada una aserción para comprobar que db_order_status es igual a pending, o al estado esperado.

Así, una respuesta 201 Created no ocultará un registro persistido con status = 'draft'.

Paso 4: reutilizar valores extraídos de la base de datos

La extracción también sirve para encadenar solicitudes.

Imagine que al crear un pedido el servidor genera una fulfillment_ref interna. La API no la devuelve, pero sí se guarda en orders. La siguiente solicitud necesita ese valor:

SELECT fulfillment_ref
FROM orders
WHERE id = {{order_id}};
Enter fullscreen mode Exit fullscreen mode

Configure:

  • Nombre de Variable: fulfillment_ref
  • Expresión JSONPath: $[0].fulfillment_ref

La siguiente solicitud puede usar directamente:

{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

Por ejemplo:

GET /api/fulfillments/{{fulfillment_ref}}
Enter fullscreen mode Exit fullscreen mode

Es el mismo patrón de encadenamiento usado con respuestas HTTP, pero la fuente de verdad es la base de datos. Consulte pasar datos entre pasos de prueba y orquestación de pruebas de API y paso de datos.

MongoDB y Redis: variantes NoSQL

El procesador también funciona con almacenes NoSQL, aunque la configuración cambia. MongoDB y Redis son funciones de pago. Consulte la documentación de Apidog para conocer todos los campos disponibles.

MongoDB

Añada una Operación de Base de Datos y seleccione MongoDB. En lugar de SQL, encontrará un menú de Tipo de Operación con:

  • Buscar
  • Insertar
  • Actualizar
  • Eliminar
  • Ejecutar Comando de Base de Datos

Para operaciones CRUD, debe indicar el Nombre de la Colección. La Condición de Consulta acepta JSON:

{ "_id": "65486728456e79993a150f1c" }
Enter fullscreen mode Exit fullscreen mode

Apidog convierte automáticamente una cadena de ID coincidente a ObjectId. Cuando necesite tipos BSON, puede usar:

  • ISODate(...)
  • ObjectId(...)
  • NumberDecimal(...)
  • NumberLong(...)

El manual de MongoDB explica cómo se asignan estos valores.

La documentación de MySQL describe la extracción con JSONPath a variables. La documentación de MongoDB y Redis no describe el mismo mecanismo de Extraer Resultado a Variable. Úselo para sembrar y verificar estado, pero valide el comportamiento de extracción en la Consola antes de depender de él.

Redis

La conexión Redis solicita:

  • Host
  • Puerto
  • Contraseña
  • Índice de Base de Datos

Las operaciones visuales admiten GET, SET y DELETE.

Para leer una sesión:

Clave: user:session:123
Operación: GET
Enter fullscreen mode Exit fullscreen mode

Para comandos no cubiertos por el menú, use Ejecutar Comando Redis:

KEYS user:*
Enter fullscreen mode Exit fullscreen mode

Esto resulta útil para confirmar que la API escribió una entrada en caché o para borrarla antes de probar que un endpoint la vuelve a crear.

Variaciones y límites avanzados

Antes de construir una suite grande, tenga en cuenta lo siguiente:

  • Bucles: dentro de un paso ForEach, haga referencia al elemento actual con {{$.StepID.element.field}}, donde StepID es el ID real del paso de bucle.
  • Ramificación según valores de BD: extraiga un estado y dirija el escenario según su valor. Combine lecturas de base de datos con lógica condicional en escenarios de prueba de API.
  • Enrutamiento por entorno: defina una conexión por entorno para que Apidog seleccione la adecuada automáticamente.
  • Procedimientos almacenados: la interfaz visual no admite operaciones complejas como procedimientos almacenados. Mantenga los pasos en sentencias directas.
  • Oracle: requiere tener instalado Oracle Client en la máquina local antes de conectarse.

Administrar credenciales por entorno

No permita que una prueba apunte a producción por accidente.

Cree una conexión de base de datos por entorno:

  • local
  • staging
  • Otros entornos que necesite

Cada conexión tendrá su propio host, usuario y contraseña. Después, seleccione el entorno en el menú desplegable de la esquina superior derecha.

Apidog enruta las consultas a la conexión correspondiente:

  • Con staging, el SELECT se ejecuta contra staging.
  • Con local, el mismo paso usa la base de datos local.

No necesita modificar el SQL entre entornos. Además, como las credenciales se guardan localmente y no se sincronizan con el proyecto en la nube, las contraseñas de producción no quedan expuestas en el proyecto compartido.

Automatizar el flujo con la CLI de Apidog

Cuando el escenario funcione en la aplicación, ejecútelo en CI para comprobar la base de datos en cada pull request.

Instale la CLI e inicie sesión:

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Enter fullscreen mode Exit fullscreen mode

Ejecute un escenario por ID y seleccione el entorno:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Opciones principales:

  • -t: ID del escenario de prueba.
  • -e: ID del entorno.
  • -r: reportero: cli, html o junit.

Puede usar varios reporteros separados por comas:

apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r html,cli
Enter fullscreen mode Exit fullscreen mode

Las conexiones de base de datos son locales, por lo que el ejecutor de CI necesita la configuración exportada para acceder a la base de datos.

Si ejecuta escenarios con conjuntos de datos, consulte pruebas impulsadas por datos con la CLI de Apidog. Para ejecuciones periódicas, revise la programación de pruebas de API con Apidog.

Preguntas frecuentes

¿Qué bases de datos son gratuitas y cuáles son de pago?

MySQL, SQL Server 2014 o posterior, PostgreSQL y Oracle están incluidos en el plan gratuito. ClickHouse, MongoDB y Redis requieren un plan de pago. Descargue Apidog para probar primero las bases de datos disponibles de forma gratuita.

¿Puedo usar un valor de la base de datos en una solicitud posterior?

Sí. Añada un Postprocesador con una operación de base de datos, ejecute un SELECT y configure Extraer Resultado a Variable con JSONPath, por ejemplo:

$[0].fulfillment_ref
Enter fullscreen mode Exit fullscreen mode

Después, úselo como {{nombre_variable}}. Consulte pasar datos entre pasos de prueba.

¿Mi equipo obtiene automáticamente mis conexiones de base de datos?

No. Las credenciales se almacenan localmente en cada cliente y no se sincronizan con la nube. Cada integrante debe configurar su conexión.

¿Por qué falla mi conexión a MySQL 8?

MySQL 8 usa caching_sha2_password por defecto, y este plugin puede bloquear la conexión. Cambie el usuario a mysql_native_password:

ALTER USER 'tester'@'%'
IDENTIFIED WITH mysql_native_password BY '...';
Enter fullscreen mode Exit fullscreen mode

¿Puedo ejecutar procedimientos almacenados?

No desde la interfaz visual. Use sentencias estándar SELECT, INSERT, UPDATE y DELETE. Las operaciones complejas, como procedimientos almacenados, no son compatibles.

Conclusión

Las consultas de base de datos convierten una prueba de API de “la respuesta parecía correcta” a “los datos persistidos son correctos”.

El flujo recomendado es:

  1. Siembre datos conocidos en un Preprocesador.
  2. Ejecute la solicitud HTTP.
  3. Verifique la fila persistida en un Postprocesador.
  4. Extraiga valores generados por el servidor para encadenar solicitudes.
  5. Use una conexión por entorno para ejecutar los mismos pasos de forma segura en local o staging.

Empiece con una conexión MySQL de desarrollo y añada un Postprocesador que consulte la fila creada por su siguiente solicitud. Descargue Apidog para probarlo.

Top comments (0)