JavaScript Definition

Overview of the JavaScript Definition of Test Cases

The following is intended to help understanding of the execution environment that is used to evaluate the JavaScript definition of your test case.

The test code you provide is used to generate a test configuration containing a description of your targets, arrival phases as well as test scenarios and steps.

JavaScript Environment

The JavaScript definition that is used to describe the test case is executed only ONCE by our API when saving your test case or uploading via the forge CLI tool. There is no JavaScript being executed when a test is running. This means the JavaScript is executed once before you actually run a test case and without any concrete test data or other state. Functions like getVar() or session.ds.generateFrom().get() return internal placeholders that will be replaced during the actual test run execution later.

Note that the JavaScript environment is a minimal environment, so you will not find any browser APIs (like window or navigator) nor any other system APIs like in a Node.js context. It is also not possible to load any external JavaScript libraries.

Placeholders and JSON.stringify

As mentioned above, functions like getVar(…) or generateFrom().get(…) return placeholder strings. Using this placeholder for example with JSON.stringify() may yield unexpected results:

session.setVar("user_id", 12345);
session.post("/login", {
    payload: JSON.stringify({
        user: session.getVar("user_id")
    })
})

In this example the request would send {"user": "12345"} as its payload. Note that the user field is a string. The same behaviour occurs when taking values from extractions or data sources (instead of setVar()).

To work around this you can use a marker and replace that together with the double quotes (") after generating the JSON string:

payload: JSON.stringify({
  "user_id": "__user_id__"
}).replace(/"__user_id__"/, session.getVar("user_id"))

Session and Context

As mentioned above, we run the Javascript definition once to build an internal configuration representation of your test case. To associate your steps (requests, conditionals, and so on), we are passing around a session or context parameter:

definition.session("hello-world", function(session) {
  session.request("/", { tag: "homepage" })

  // Do another request, if session_id is present
  session.if (session.getVar("session_id"), "!=", "", function(context) {
    context.post("/logout", {tag: "logout"})
  })
})

In this example, the first request uses the session parameter in the hello-world session, while the session.if() callback receives a context parameter that the second request uses. Using session for the second request would produce an error because no step was associated with the conditional. Also, the second request would always run because it is associated with the session, not the context. Therefore, you must make sure to use the provided context, otherwise steps might run at the wrong time.

This pattern of receiving a context parameter is visible in all steps that create any kind of substeps, such as if, doWhile, chooseByProbability, and so on.

JavaScript DSL

Inside the JavaScript definition you can define your test case by interacting with the global definition variable that is provided.

See the following articles for the various elements you can define via the API:

See Other

Last modified September 23, 2024