v1.11.0

Changelog

Features

• Added an action type NODE_JS which cn execute arbitrary Node.js code. The main purpose of this new action type is to perform transformations on variables, but obviously it can be abused to do basically anything. It works by providing JavaScript expressions which should be evaluated and assigned to variables. The main difference in comparison other situations where variables can be injected is that this is not simply string replacement but you can actually access the real variables. This means you can correctly work with data that does not nicely convert to strings implicitly, e.g. Buffers. Here is an example of a NODE_JS action:

  type: NODE_JS
  variables:
    foo: '"bar"' # foo will be assigned the string "bar"
    baz: '{{someVar}} + 42' # baz will be assigned the result of adding 42 to the variable someVar
    anotherVar: 'const { URL } = require("url"); new URL("http://this.is.a.test")' # anotherVar will be asigned an URL object pointing to "http://this.is.a.test"

• When drawing diagrams, dashes in the names / URLs of services and brokers are no longer replaced by underscores, they will be printed as-is. Also diagram drawing does not break if other special characters that have a meaning in PlantUML app are used here. Note however, that using quotes is not supported and will break diagram drawing.

v1.10.0

Changelog

Features

• Added the possibility to use variable injection an JavaScript code evaluation in the parameters exchange, queue, routingKey, username and password of AMQP_LISTEN actions.

Bugfixes

• Variable injections now works correctly for the data parameter of REST actions, if it is given as a list. See #51.

v1.9.2

Changelog

Bugfixes

• Fixed a bug with HTTP response payloads still not being displayed correctly in drawn diagrams. Binary data is now displayed as the JSON representation of the Buffer.

v1.9.1

Changelog

Bugfixes

• Responses from REST actions are now correctly displayed in the drawn UML diagrams. Binary responses are displayed as hexadecimal string.

v1.9.0

Changelog

Features

• Added the possibility to define client certificates and keys for REST actions inline. To do this, simply provide the parameters clientCertificate and clientKey with the corresponding data:

  type: REST
  service: someService
  endpoint: /
  clientCertificate: |
      -----BEGIN CERTIFICATE-----
      …
      -----END CERTIFICATE-----
  clientKey: |
      -----BEGIN PRIVATE KEY-----
      …
      -----END PRIVATE KEY-----

  If you want to reference a certificate or a key from a file, you can do this by providing the path to the file to the parameters clientCertificate and clientKey respectively, prefixed with the string file::

  type: REST
  service: someService
  endpoint: /
  clientCertificate: 'file:path/to/the/certificate.pem'
  clientKey: 'file:path/to/the/key.pem'

  Additionally, it is possible to access variables and evaluate JavaScript code in these two parameters, so for example you could load the data from environment variables:

  type: REST
  service: someService
  endpoint: /
  clientCertificate: '{{{process.env.CLIENT_CERT}}}'
  clientKey: '{{{process.env.CLIENT_KEY}}}'

• Binary response bodies received from REST actions are now passed as Buffers to response validation and variable extraction.

Breaking Changes

• The REST action parameters clientCertificatePath and clientCertificateKey have been removed in favor of clientCertificate and clientKey.
• Binary response bodies received from REST actions are now passed as Buffers to response validation and variable extraction.

v1.8.0

Changelog

Features

• Adjusted logging format to improve readability. Here is an example of the new format:

  2019-10-24T08:32:22.410Z | no scenario     | no action       |  INFO | RUNNING: scenario(s): src/tests/integration/rest/resources/scenarios/s4-restExpectingClientToBeUnauthorized.yaml (actions: src/tests/integration/rest/resources/actions, out: ./out, envDir: src/tests/integration/rest/resources/environment, numberOfScenariosRunInParallel: 1, environmentNameToBeUsed: config)
  2019-10-24T08:32:22.419Z | s4-restExpecti… | rest-secure     |  INFO | #### (A): rest-secure ##############################################################################
  2019-10-24T08:32:22.437Z | s4-restExpecti… | rest-secure     | ERROR | Response: 401 (Unauthorized)
  2019-10-24T08:32:22.438Z | s4-restExpecti… | rest-secure     | ERROR |
  2019-10-24T08:32:22.439Z | s4-restExpecti… | rest-secure     |  INFO | ######################################################################### Time: 19.83 ms ###########
  2019-10-24T08:32:22.439Z | s4-restExpecti… | no action       |  INFO | #### SUMMARY: s4-restExpectingClientToBeUnauthorized ###############################################
  2019-10-24T08:32:22.440Z | s4-restExpecti… | no action       |  INFO | NOK: rest-secure                                        19.83 ms
  2019-10-24T08:32:22.440Z | s4-restExpecti… | no action       |  INFO | ########################################################################################
  

• Added the functionality to WebSocket actions and MQTT actions to fail the scenario they belong to if the number of expected messages differs from the number of actually received messages. Earlier, only an error log was printed in this case but there was no impact on the outcome of the whole scenario.
• Added the possibility to disable diagram drawing. Diagram drawing can be disabled by passing drawDiagrams: false as part of the configuration object to runMultipleScenariosWithConfig.
• Added a new function runMultipleScenariosWithConfigAsync to the API which takes the same parameters as runMultipleScenariosWithConfig but does not kill the process when a scenario fails. Instead it returns a Promise<bolean>. The boolean indicates whether or not the scenarios were run sucessfully with true indicating success and false indicating failure.
• Added support client certificate based authentication to REST actions which use SSL. To use this feature, simply set the fields clientCertificatePath and clientKeyPath in your REST action definition. Here is an example:

  type: REST
  service: https://some.url
  endpoint: /
  method: GET
  clientCertificatePath: 'src/tests/integration/rest/resources/certs/alice_cert.pem'
  clientKeyPath: 'src/tests/integration/rest/resources/certs/alice_key.pem'

• Added support for listening for AMQP messages by adding a new action of type AMQP_LISTEN. Similar to WebSocket actions, it runs until the end of the whole scenario and the success of the action is determined by counting the number of received messages which conform to one of several given filters. The action definition looks as follows:

  type: AMQP_LISTEN
  broker: amqp://some.url 
  exchange: myExchange
  queue: testQueue;
  routingKey: someRoutingKey
  username: foo
  password: bar
  expectedNumberOfMessages: 2
  messageFilter:
    - "msg.id === 1234"

  parameter	description	required	default
  type	Determines the type of the action. Use AMQP_LISTEN for AMQP_LISTEN actions	yes
  broker	The address of the broker. Both amqp and amqps are supported. Alternatively, this can be a name defined in the environment configuration, similar to how the service field works for REST and WebSocket actions.	yes
  exchange	The exchange from which to receive messages.	yes
  queue	The queue from which to consume messages. It is assumed to be an auto deleteable queue and if it does not exist yet, it will be created. If the queue already exists with a non matching configuration, the action will fail.	yes
  routingKey	The routing key to use to bind the queue to the exchange.	yes
  username	The username to use for authenticating with the broker. This field is optional.	no	""
  password	The password to use for authenticating with the broker. This field is optional.	no	""
  expectedNumberOfMessages	The number of messages that is expected to be received.	yes
  messageFilter	A list of filters which define which messages are considered for expectedNumberOfMessages. A message is considered if it matches one of the given filters. If no filter is given, all messages are considered.	no	[]

• Added the possibility to configure REST actions to expect a binary reponse body. This can be achieved by setting the field expectBinaryResponse to true in the REST action definition. If this field is not given or set to false, the response is expected to be a string encoded as UTF-8. For now, the response is still converted to a string before passing it to validation and variable extraction but this will be changed in the future.

Bugfixes

• Query parameters for REST actions now work correctly. Additionally, the query parameters are now URL encoded. For example the REST action definition

  type: REST
  service: https://some.url
  endpoint: /foo
  method: GET
  queryParameters:
      bar: +123
      baz: a=b

  will result in the URL https://some.url/foo?bar=%2B123&baz=a%3Db.
• Subdirectories in the actions directory do not break action loading anymore. Instead they are simply ignored. See #11.

Breaking Changes

• By default, WebSocket actions and MQTT actions, which receive a different number of messages than expected, will make the scenario they belong to fail. If you want to revert back to the old behavior for this actions, simply set the allowFailure fields to true in your action definition. Here is an example:

  type: WEBSOCKET
  service: wss://some.url/
  endpoint: /ws
  expectedNumberOfMessages: 4
  allowFailure: true

• Earlier, when providing several scenarios to runMultipleScenariosWithConfig, there were cases where if one scenarios failed, all other running scenarios were cancelled immediately and the process returned with an error. This depended on several different factors but in particular on the number of scenarios that were run in parallel. From this release on, all scenarios will always finish running regularly and only then will the process return with an error if one of them failed.

1.2.23

update nodemon dependency for security reasons