Script Loading Order in ReAPI

Understanding the script loading order in ReAPI is crucial for ensuring smooth execution and proper dependency management. ReAPI loads scripts in a specific sequence to ensure all dependencies are available before execution.

Loading Order Overview

Scripts in ReAPI are loaded in the following order:

1. External Libraries (User-Managed):

   • External scripts registered by the user, such as those hosted on private servers or published to an NPM registry.
   • These libraries provide reusable utility functions and dependencies that can be used across test cases.
   • This means external utilities are available in any function, including ReAPI-managed global scripts.

2. Managed Global Utilities (ReAPI-Managed):

   • Custom global utility functions created within ReAPI’s web editor.
   • These functions offer centralized reusable logic to simplify test case design.

3. Other Functions:

   • Includes test-specific functions such as custom assertions and value generators.
   • These functions are the last to load and rely on previously loaded utilities.

Ensuring Script Stability and Uniqueness

All script components—including API hooks, custom assertions, and value functions—MUST have a unique ID.

• For ReAPI-managed components, a random unique ID is automatically assigned by the platform.
• For externally managed libraries, you MUST manually assign a unique ID to each component to prevent conflicts.

Once a component is enabled, it SHOULD NEVER be disabled, as doing so can result in errors for test cases that reference it.

Example Scenario

Consider the following scenario:

1. A function calculateTax is enabled in an external library and used within a ReAPI-managed global script.
2. The global script calls calculateTax to perform tax calculations across test cases.
3. In the next version of the external library, if calculateTax is removed or disabled, the global script will throw an error: ReferenceError: calculateTax is not defined, leading to test failures.

To avoid such issues, ensure components are fully tested before enabling and never disable them once referenced in test cases.

Built-in Libraries

ReAPI provides built-in support for commonly used libraries, including:

• Lodash: A popular utility library for working with arrays, objects, and functions.
  • Lodash functions can be accessed using the _ prefix.
  Example Usage:

  const sortedArray = _.sortBy([3, 1, 2]);
  console.log(sortedArray); // Output: [1, 2, 3]

Best Practices

• Use External Libraries for Complex Logic:
  • Offload complex processing to external scripts to leverage the full power of development tools and frameworks.
• Keep Global Utilities Focused:
  • Use ReAPI-managed global scripts for frequently used, lightweight utility functions.
• Leverage Built-in Libraries:
  • Utilize built-in libraries such as Lodash to avoid unnecessary dependencies and simplify scripting.

Conclusion

By understanding and adhering to ReAPI’s script loading order, you can ensure optimal performance and maintainability of your test scripts. Whether leveraging external libraries, built-in utilities, or custom global scripts, following best practices will help streamline your testing workflow.