TL;DR
Las variables establecidas durante la ejecución manual de solicitudes a menudo desaparecen cuando se ejecuta la misma colección en el Collection Runner de Postman. La causa principal es una falta de coincidencia en el alcance de las variables: pm.environment.set se comporta de manera diferente en el runner que en el modo manual, y las variables de colección funcionan de manera diferente a las variables de entorno. Esta guía explica exactamente por qué sucede esto y cómo solucionarlo, y luego muestra cómo Apidog maneja el alcance de las variables de una manera que es más difícil de configurar incorrectamente por accidente.
Introducción
Has estado probando una API manualmente en Postman. Ejecutas una solicitud de inicio de sesión, el script de pre-solicitud establece un token de autenticación y las solicitudes posteriores lo recogen sin problemas. Todo funciona.
Luego haces clic en "Ejecutar Colección". El runner se inicia, la solicitud de inicio de sesión tiene éxito, pero la siguiente solicitud falla con un 401. El token no está.
Este escenario aparece repetidamente en Stack Overflow y en los foros de la comunidad de Postman. Las respuestas suelen apuntar al alcance de las variables, pero rara vez explican el panorama completo de por qué el comportamiento difiere entre las pruebas manuales y el runner.
Comprender esto requiere comprender la jerarquía de alcance de variables de Postman. Una vez que lo veas claramente, la solución es sencilla.
Jerarquía de alcance de variables de Postman
Postman tiene cinco alcances de variables, listados de mayor a menor prioridad:
- Variables locales – disponibles solo dentro de la ejecución del script actual, no accesibles entre solicitudes
- Variables de datos – cargadas desde un archivo CSV o JSON para ejecuciones basadas en datos
- Variables de colección – con alcance a la colección, persisten entre solicitudes en esa colección
- Variables de entorno – con alcance al entorno seleccionado, persisten entre colecciones
- Variables globales – disponibles en cualquier colección en cualquier entorno
Cuando Postman resuelve una referencia de variable como {{token}}, recorre esta lista y utiliza la primera coincidencia que encuentra.
El problema es que "persisten" significa cosas diferentes dependiendo de cómo se esté ejecutando la colección.
Por qué las variables desaparecen en el Collection Runner
La distinción entre valor actual y valor inicial
Cada variable de Postman tiene dos campos: "valor inicial" y "valor actual".
- El valor inicial se sincroniza con la nube de Postman y se comparte con los compañeros de equipo.
- El valor actual es local para tu máquina y nunca se sincroniza.
Cuando estableces una variable programáticamente en un script usando pm.environment.set('token', value), Postman actualiza el valor actual en tu entorno activo.
En el modo de prueba manual, esto funciona como se espera porque tus valores actuales locales persisten entre ejecuciones de solicitudes individuales dentro de la misma sesión.
En el Collection Runner, el comportamiento cambia. El runner inicia cada ejecución desde el estado actual del entorno al comienzo de la ejecución. Los scripts que actualizan variables durante la ejecución funcionan correctamente dentro de esa ejecución. Pero si el runner está configurado para borrar las variables entre ejecuciones, o si el valor inicial está vacío y el runner usa una instantánea de entorno fresca, puedes terminar en un estado donde tu script se ejecuta pero la variable no parece persistir.
El problema de la variable de entorno vs. la variable de colección
Aquí está la trampa más común. Estás estableciendo una variable en un script de post-respuesta:
pm.environment.set('token', pm.response.json().access_token);
Esto establece una variable en el entorno activo. Pero el Collection Runner tiene una opción llamada "Mantener valores de variables". Si esta casilla está desmarcada (por defecto está desmarcada), el runner restablece las variables de entorno a sus valores iniciales después de la ejecución. Cualquier valor establecido durante la ejecución se descarta.
Si estás ejecutando la colección sin un entorno seleccionado, pm.environment.set falla silenciosamente. No hay un entorno en el que escribir. La variable desaparece.
La falta de coincidencia de alcance entre el modo manual y el modo runner
En las pruebas manuales, normalmente tienes un entorno seleccionado y persiste durante toda tu sesión de Postman. Cuando ejecutas una solicitud, estableces una variable y ejecutas otra solicitud, todas ocurren en el mismo contexto de entorno persistente.
El Collection Runner crea un contexto de ejecución separado. Carga el estado del entorno al principio, ejecuta todas las solicitudes y luego (a menos que marques "Mantener valores de variables") devuelve el entorno a su estado anterior a la ejecución.
Esto significa que las variables establecidas por una solicitud en el runner están disponibles para las solicitudes subsiguientes en la misma ejecución, pero no persisten en tu panel de entorno después de que termina la ejecución a menos que las mantengas explícitamente.
Soluciones
Solución 1: Marcar "Mantener valores de variables" en el runner
En el Collection Runner, antes de hacer clic en Ejecutar:
- Busca la opción "Mantener valores de variables" en el panel de configuración del runner.
- Marca esta casilla.
Esto le indica al runner que vuelva a escribir cualquier cambio de variable en tu entorno activo una vez que finalice la ejecución. Las variables establecidas por los scripts durante la ejecución serán visibles en tu panel de entorno cuando finalice la ejecución.
Cuándo usar esto: Cuando deseas que el runner actualice el estado compartido, como la actualización de un token de autenticación que otras herramientas o ejecuciones subsiguientes utilizarán.
Cuándo no usar esto: Cuando estás ejecutando varias iteraciones y las variables establecidas en la iteración 1 contaminarían la iteración 2. En ese caso, usa archivos de datos o restablece las variables explícitamente al comienzo de cada iteración.
Solución 2: Usar variables de colección en lugar de variables de entorno para el estado dentro de la ejecución
Si una variable solo necesita compartirse entre solicitudes dentro de la misma ejecución de colección, usa variables de colección en lugar de variables de entorno:
// En el script de post-respuesta de tu solicitud de inicio de sesión:
pm.collectionVariables.set('token', pm.response.json().access_token);
// En el script de pre-solicitud de las solicitudes subsiguientes:
const token = pm.collectionVariables.get('token');
Las variables de colección siempre están disponibles en el runner, independientemente de si se selecciona un entorno. Persisten durante la duración de la ejecución de la colección. Son el alcance correcto para valores que se establecen y consumen dentro de una sola colección.
Solución 3: Asegurarse de que se seleccione un entorno antes de ejecutar
pm.environment.set falla silenciosamente cuando no hay un entorno activo. Antes de ejecutar la colección:
- Abre el Collection Runner.
- Verifica que se seleccione un entorno en el menú desplegable "Entorno".
- Si no necesitas variables a nivel de entorno, usa variables de colección en su lugar (Solución 2).
Solución 4: Usar valores iniciales para variables que siempre deben existir
Si una variable como baseUrl necesita estar disponible desde la primera solicitud en una ejecución, configúrala como el valor inicial en tu entorno, no solo como el valor actual.
En el editor de entorno:
- Establece el campo "Valor inicial", no solo el campo "Valor actual".
- El valor inicial es lo que el runner usa como estado inicial.
Si solo se establece el valor actual y el runner no tiene acceso a tus valores actuales locales (por ejemplo, un compañero de equipo que ejecuta la colección, o una ejecución de Newman/Apidog CLI), la variable comienza vacía.
Solución 5: Depurar con registro en consola
Añade console.log a tus scripts de pre-solicitud y post-respuesta para ver exactamente lo que está sucediendo:
// Script de pre-solicitud
console.log('token antes de la solicitud:', pm.collectionVariables.get('token'));
console.log('token de entorno:', pm.environment.get('token'));
Abre la Consola de Postman (Ver > Mostrar Consola de Postman) antes de ejecutar la colección. Los registros te mostrarán exactamente de qué alcance se está leyendo cada variable y qué valor contiene en cada paso.
Cómo Apidog maneja el alcance de las variables
Apidog utiliza la misma jerarquía de alcance: global, entorno, colección y local. La diferencia clave radica en la interfaz de usuario.
En el editor de variables de Apidog, los valores iniciales y actuales se muestran con etiquetas y colores explícitos. La interfaz hace que sea más difícil establecer accidentalmente solo el valor actual. Cuando un script establece una variable usando pm.environment.set (que Apidog admite para la compatibilidad con Postman), el panel de entorno se actualiza visualmente en tiempo real para que puedas ver el cambio.
El ejecutor de pruebas de Apidog tampoco restablece los valores de las variables entre pasos a menos que lo configures explícitamente para que lo haga. El comportamiento predeterminado es preservar el estado de las variables entre solicitudes en una ejecución, lo que coincide con lo que la mayoría de los desarrolladores esperan de las pruebas manuales.
Para escenarios de equipo, el modelo de Apidog "local-first" significa que las variables de entorno se almacenan en el disco. No hay sincronización en la nube que sobrescriba tus valores actuales entre ejecuciones.
Resumen de errores comunes
| Error | Síntoma | Solución |
|---|---|---|
| No se seleccionó ningún entorno | pm.environment.set falla silenciosamente |
Seleccionar un entorno o usar variables de colección |
| Solo se estableció el valor actual | Variable faltante en CI o en la máquina del compañero de equipo | Establecer valor inicial en el editor de entorno |
| "Mantener valores de variables" desmarcado | Las variables se restablecen después de que el runner finaliza | Marcar "Mantener valores de variables" en la configuración del runner |
| Uso de variables de entorno para el estado dentro de la ejecución | Funciona en modo manual, falla en el runner | Cambiar a pm.collectionVariables.set |
| Comprobando el alcance incorrecto en los registros | La variable existe pero se usa un valor incorrecto | Registrar ambos alcances y verificar la prioridad de resolución |
Preguntas frecuentes
¿Por qué pm.environment.set funciona en modo manual pero no en el runner?En modo manual, tienes una sesión de entorno persistente. En el runner, el entorno se carga al comienzo de la ejecución y, por defecto, se restablece al final. Los scripts que establecen variables durante la ejecución siguen funcionando para las solicitudes subsiguientes en esa ejecución, pero los cambios no persisten en tu entorno a menos que se marque "Mantener valores de variables".
¿Cuál es la diferencia entre pm.environment.set y pm.collectionVariables.set?pm.environment.set escribe en el entorno activo, que se comparte entre todas las colecciones que utilizan ese entorno. pm.collectionVariables.set escribe en un alcance vinculado a la colección específica. Para valores que solo importan dentro de una ejecución de colección, las variables de colección son más apropiadas y no requieren que se seleccione un entorno.
¿Ocurre este problema en Newman?Sí. Newman tiene el mismo modelo de alcance. Por defecto, Newman inicia cada ejecución con los valores iniciales del entorno exportado y no persiste los cambios después de la ejecución a menos que uses el flag --export-environment para escribir el estado final del entorno en un archivo.
¿Qué es el flag --export-environment en Newman?Le indica a Newman que escriba el estado final del entorno, incluidos los valores establecidos por los scripts durante la ejecución, en un archivo JSON después de que finalice la ejecución. Luego puedes pasar ese archivo como el entorno para la siguiente ejecución. Esto es útil para pipelines donde una ejecución genera tokens utilizados por la siguiente.
¿Apidog es compatible con pm.collectionVariables.set?Sí. Apidog es compatible con la API de scripting completa de Postman, incluyendo pm.collectionVariables.set, pm.collectionVariables.get, pm.environment.set y pm.environment.get. Las colecciones migradas de Postman utilizan la misma sintaxis de script.
¿Cómo paso variables de una colección a otra en Postman?Usa variables globales: pm.globals.set('token', value). Las variables globales persisten entre colecciones y entornos durante la vida útil de la sesión de Postman. Ten cuidado con este enfoque en entornos de equipo, ya que las variables globales no tienen alcance y pueden crear colisiones de nombres.
Los problemas de alcance de variables en Postman son una de las fuentes más fiables de falsos negativos en los conjuntos de pruebas de API. Una prueba que pasa manualmente pero falla en el runner no es una prueba en la que puedas confiar. Comprender el modelo de alcance, usar el setter correcto para el contexto adecuado y marcar "Mantener valores de variables" cuando sea apropiado son los tres movimientos que resuelven la mayoría de estos problemas.