As a tester writing tests with ALT, I want to be able to specify the values for parameters using javascript so that I can use dynamic data in addition to static data.
Currently it is only possible to set parameters (in path, form, json body) to static values or to some value generated by a previous action. There are some cases where it would be nice to be able to use dynamically generated data that does not depend on a previous action, e.g. using the current date, generating random values and similar things. This can be worked around by using a previous action and setting the variable there, but this is a hacky workaround.
Some possible solutions:
Allow inline javascript in the definition of parameters, which is executed and the parameter is set to the result. This could look something like
It should also be possbile to define the variables in the in the action itself, e.g. with a new field `preVariables`:
```yaml
# my-action.yaml
type: REST
service: name-of-the-service
endpoint: /some/endpoint
method: POST
preVariables:
date: "(new Date()).toISOString()"
headers:
Content-Type: application/json
data:
var1: "{{date}}"
I believe the first of the two options is a lot more user friendly, but it might be more difficult to implement.
As a tester writing tests with ALT, I want to be able to specify the values for parameters using javascript so that I can use dynamic data in addition to static data.
Currently it is only possible to set parameters (in path, form, json body) to static values or to some value generated by a previous action. There are some cases where it would be nice to be able to use dynamically generated data that does not depend on a previous action, e.g. using the current date, generating random values and similar things. This can be worked around by using a previous action and setting the variable there, but this is a hacky workaround.
Some possible solutions:
s1-my-scenario.yaml
description: "some description" variables: date: "(new Date()).toISOString()"
actions:
I believe the first of the two options is a lot more user friendly, but it might be more difficult to implement.