Global Script Guide

Global scripts in ReAPI provide a centralized way to define reusable utility functions that can be accessed across all script components within the platform. Unlike external libraries, global scripts are created and maintained directly within the ReAPI web editor.

Key Features of Global Scripts

1. Web-Based Management

   • Global scripts are managed within the ReAPI web application, providing easy access and version control.

2. Execution Order

   • Global scripts are loaded after external libraries, allowing seamless integration with registered external functions.

3. Built-in Libraries

   • Limited built-in libraries are available, including:
     • Lodash (_): Utility functions for arrays, objects, and strings.
     • CryptoJS: Secure encryption and hashing utilities.

4. Scoped Availability

   • Global scripts can be used in the following web-based script components:
     • API Hooks (beforeRequest, afterResponse)
     • Custom Assertions
     • Value Functions

5. Editing Restrictions

   • Global scripts can only be edited within the ReAPI web application, ensuring controlled and secure updates.

Best Practices for Writing Global Scripts

To ensure scalability, maintainability, and conflict-free usage, follow these best practices:

1. Use Class-Based Structure

   • Encapsulate utilities within a class to avoid polluting the global namespace.

   class $$DateUtils {
     static formatToISO(date) {
       return new Date(date).toISOString();
     }
   }

2. Follow Proper Naming Conventions

   • Use unique prefixes (e.g., $$YourPrefix_) to prevent conflicts with other scripts.

3. Keep Functions Modular

   • Create focused, single-purpose functions to improve reusability and readability.

4. Test Thoroughly Before Use

   • Validate global script functions before integrating them into test workflows.

5. Avoid Hardcoded Values

   • Use environment variables or context data for flexibility across environments.

Example: Using Global Scripts in a Value Function

Once a global script is defined, it can be used in web-based script components like value functions:

function getFormattedTimestamp() {
  return $$DateUtils.formatToISO(new Date());
}

Renaming Functions or Classes

Careful planning of class and function names is crucial to avoid renaming issues. If renaming becomes necessary, follow these steps to maintain backward compatibility:

Renaming a Class

Assign the old class name to the new one using a constant reference to ensure seamless compatibility:

class $$NewDateUtils {
  static formatToISO(date) {
    return new Date(date).toISOString();
  }
}
 
/** @deprecated Use $$NewDateUtils instead. */
const $$OldDateUtils = $$NewDateUtils;

Renaming a Function

Preserve the old function name by calling the new function within it to ensure compatibility:

/** @deprecated Use newFormatToISO instead. */
function oldFormatToISO(date) {
  return newFormatToISO(date);
}
 
function newFormatToISO(date) {
  return new Date(date).toISOString();
}

Always include the @deprecated JSDoc annotation to notify users that the old function or class should no longer be used in new test cases.

Next Steps

Start creating your global scripts to centralize reusable logic and enhance your test automation capabilities. For complex logic requiring external dependencies, consider using External Libraries.