Variables de entorno en scripts E2E: secretos seguros en JMO Labs

Cuando escribes scripts E2E que interactúan con aplicaciones reales, tarde o temprano necesitas datos que no deberían estar en el código: tokens de API, credenciales de acceso, URLs de entornos privados. Hardcodear estos valores es un riesgo de seguridad y un problema de mantenimiento. En JMO Labs hemos resuelto esto con las variables de script.

Qué son las variables de script

Las variables de script son pares clave-valor que se definen una vez en la configuración de JMO Labs y se inyectan automáticamente en cada ejecución de scripts E2E. Se acceden con la sintaxis variables.NOMBRE, sin imports ni configuración adicional en el script. Si te interesa la solución que adoptamos, en la gestión de secretos con Infisical lo explicamos con detalle.

Cada variable tiene tres campos:

• El nombre, un identificador en formato SCREAMING_SNAKE_CASE (por ejemplo, API_KEY, PRIVATE_TOKEN).

• El valor, el dato que se inyectará en el script.

• Una descripción opcional que documenta para qué sirve la variable.

Modo privado: protección de datos sensibles

No todas las variables son iguales. Un BASE_URL puede aparecer sin problema en los logs, pero un PRIVATE_TOKEN no debería ser visible en ningún sitio. Para esto existe el modo privado.

Cuando una variable se marca como privada:

• Su valor se muestra enmascarado (••••••••) en la interfaz de administración.

• Se redacta automáticamente en la salida de consola y en los logs de ejecución.

• Sigue siendo accesible con normalidad dentro del script vía variables.NOMBRE.

La interfaz muestra claramente qué variables están en modo privado con una etiqueta visual, y los controles de edición y eliminación siempre están accesibles.

Cómo se usan en un script E2E

Dentro de un script, las variables están disponibles como propiedades de un objeto variables que se inyecta automáticamente en el sandbox de ejecución. El objeto es de solo lectura (Object.freeze) para evitar modificaciones accidentales.

Veamos un ejemplo real: un test de modo privado que necesita un token para activar una funcionalidad protegida.

El script comprueba si variables.PRIVATE_TOKEN está definido. Si no lo está, el test se salta la parte de activación. Si existe, lo usa para navegar a la URL de activación del modo privado:

Lo importante es que el token nunca aparece en el script, ya que se pasa desde la API a través de las variables inyectadas. Si alguien revisa el código del test, no ve credenciales. Si revisa los logs de ejecución, el valor aparece redactado.

Detalles técnicos de la implementación

Bajo el capó, las variables se gestionan con estas restricciones:

• Máximo 100 variables por instancia.

• Cada valor puede tener hasta 10 KB.

• Los nombres deben seguir el patrón [A-Z][A-Z0-9_]{0,63}, solo mayúsculas, números y guiones bajos.

• Las variables se insertan en el sandbox VM de Node.js como un objeto congelado e inmutable.

• Los valores de variables secretas se interceptan en la salida estándar y se reemplazan por [REDACTED].

El endpoint de la API (/api/script-variables) permite operaciones CRUD completas, con validación estricta del formato de nombre y un flag secret que controla el enmascaramiento.

Por qué esto importa

En testing E2E, la gestión de secretos suele ser un punto ciego. Los equipos acaban con tokens en archivos .env que se comparten por Slack, credenciales hardcodeadas en scripts de test, o variables de CI/CD que no son accesibles cuando alguien ejecuta los tests en local.

Las variables de script en JMO Labs resuelven esto con un enfoque centralizado: se definen una vez en la plataforma, están disponibles en todos los scripts, y las sensibles nunca se exponen en la interfaz ni en los logs. Simple, seguro, sin fricción. Si quieres profundizar, en Playwright como motor de testing en JMO Labs lo cubrimos en detalle.