JavaScript Definition
3 minute read
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 stormforge 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.
Placeholders are Strings
Placeholders are represented by a string, but they do not contain any actual values when executing the Javascript Definition. Using string modifier functions like substring() will break the placeholder format
and will lead to undefined behavior and may crash the test run!
You can use helpers like session.if() or session.times() to control the flow of your sessions, as they are evaluated during the test run execution.
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: