Cómo conectar MongoDB en Apidog y usarlo en pruebas de APIs (guía avanzada para QAs de servicios)

En testing de APIs, uno de los mayores retos no es ejecutar requests… sino validar que los datos realmente se persisten correctamente.

Muchos equipos QA trabajan cómodamente con SQL (PostgreSQL, MySQL), pero cuando entramos en arquitecturas modernas, es muy común encontrarnos con MongoDB (NoSQL)… y ahí es donde muchos flujos de prueba se rompen o se vuelven manuales. Hoy quiero hablarles de como en nuestro equipo lo implementamos, porque costó un buen tiempo.

En este artículo te voy a enseñar, paso a paso, cómo:

• Conectar MongoDB en Apidog
• Ejecutar consultas desde tus tests
• Usar los resultados para validaciones automáticas
• Entender cómo funciona la respuesta de Mongo (cursor, firstBatch)
• Y lo más importante: cómo integrar esto en un flujo real de QA

1. ¿Por qué usar MongoDB dentro de Apidog?

Cuando pruebas servicios, validar solo el response no es suficiente.

Necesitas confirmar:

• Que la data se guardó correctamente
• Que los valores enviados realmente existen en base
• Que no hay transformaciones inesperadas

Aquí es donde Apidog permite algo muy potente: Ejecutar queries directamente contra la base de datos dentro del flujo de test.

2. Configuración de MongoDB en Apidog

Lo clave es que necesitas al menos la versión Basic de ApiDog para poder utilizar esta conexión.

Paso 1: Ir a Database Connections

Dentro de Apidog:

Settings → Database Connections → New

Paso 2: Configurar la conexión

Selecciona:

• Database Type: MongoDB
• Host
• Port
• Username
• Password
• Database Name

⚠️ Buenas prácticas de seguridad

• No guardes credenciales en texto plano
• Usa variables de entorno o Vault
• Evita sincronizar credenciales sensibles en la nube

Esto es clave especialmente en equipos QA donde múltiples personas acceden al proyecto.

3. Ejecutando consultas Mongo desde Apidog

Dentro de un test, agrega un step:

Database Operation → Run Database Command

Aquí es donde viene la primera gran diferencia respecto a SQL.

4. MongoDB no es SQL: cambia el mindset

Si vienes de SQL, probablemente estás acostumbrado a esto:

SELECT tenant, gateway_type
FROM commerces
WHERE merchant_code = '123';

En MongoDB, esto cambia completamente:

{
  "find": "commerces",
  "filter": {
    "merchant_code": "123"
  },
  "projection": {
    "_id": 0,
    "tenant": 1,
    "gateway_type": 1
  }
}

Diferencias clave:

Diferencias clave entre SQL y MongoDB

SQL                  | MongoDB
---------------------|-------------------------
Tablas               | Colecciones
Filas                | Documentos
SELECT               | find
WHERE                | filter
Columnas             | projection

⚠️ Importante: Mongo trabaja con documentos JSON, no con estructuras tabulares.

5. Caso real de uso en QA (validación post request)

Flujo:

1. Ejecutas un POST enviando un parámetro en específico o un campo en el body, dicho post en el ejemplo devuelve un id
2. Obtienes dicho id que es el merchantCode
3. Consultas MongoDB
4. Validas que los datos del header y del body se guardaron correctamente

Query usada:

{
  "find": "commerces",
  "filter": {
    "merchant_code": "{{merchantCode}}"
  },
  "projection": {
    "_id": 0,
    "tenant": 1,
    "gateway_type": 1
  }
}

6. Cómo leer la respuesta de MongoDB en Apidog

Aquí viene una de las partes más importantes (y menos documentadas).

Mongo no devuelve directamente un array plano.

Devuelve algo así:

{
  "cursor": {
    "firstBatch": [
      {
        "tenant": "GT",
        "gateway_type": "PAYMENT"
      }
    ]
  }
}

¿Qué significa esto?

• cursor: estructura interna de Mongo para manejar resultados
• firstBatch: primer lote de resultados
• [0]: primer documento encontrado

7. Extraer valores con JSONPath

Para usar estos datos en ApiDog:

$.cursor.firstBatch[0].tenant
$.cursor.firstBatch[0].gateway_type

Y los guardas como variables de entorno:

• tenant_db
• gateway_type_db

8. Validaciones automáticas en el test

Una vez extraídos los valores, puedes hacer assertions:

Validar tenant

• El tenant enviado en el header existe en base

Validar gateway_type

• El gateway_type enviado en el request existe en base

Esto convierte tu prueba en algo mucho más robusto:

No solo validas respuesta, validas persistencia real

9. Uso adicional: preparar datos antes del test

Mongo en Apidog no solo sirve para validar.

También puedes:

• Obtener data válida antes de ejecutar un request
• Generar inputs dinámicos
• Evitar hardcodeo de datos

Esto reduce significativamente la fragilidad de tus pruebas.

10. Conclusión

Integrar MongoDB en Apidog cambia completamente la forma en la que haces QA de servicios.

Pasas de:

• Validar responses

A:

• Validar consistencia real del sistema

Y más importante aún:

Te acerca mucho más al comportamiento real del sistema en producción

12. Reflexión final

Muchos equipos QA siguen trabajando como si el sistema fuera una caja negra. Pero en arquitecturas modernas, eso ya no es suficiente. Entender cómo interactuar con bases NoSQL como MongoDB no es un “plus”. Es una necesidad.

Si estás trabajando en testing de APIs y aún no estás validando contra base de datos, probablemente estás dejando bugs pasar.