About Event-Driven test step
The Event-Driven test step is used for working with asynchronous APIs. In their case, publishers send messages (or events) to a channel on a broker, and subscribers get those messages (events) by subscribing to the channel.
In ReadyAPI, the Event-Driven test step can operate in two modes:
In Publish mode, it acts as an event publisher (or producer): it connects to a broker, sends an event, and then disconnects.
In Subscribe mode, it acts as an event subscriber (or consumer): it connects to a broker and continues consuming events as long as the connection is open.
Currently, the Event-Driven test step supports only the Kafka asynchronous API. For more information on its support, see Kafka Testing.
To use the Event-Driven test step, you need to add a Kafka service to your project.
Editing Event-Driven test step
Each Event-Driven test step is based on a request defined in your API. ReadyAPI takes the protocol, operation, channel, and endpoint specified for this request. You can link your test step to another operation of the same type to change the channel. You can change the endpoint in the test step editor.
Here is a brief description of the Event-Driven test step editor:
The AsyncAPI protocol that will be used for the test step (currently, only Kafka is available).
The endpoint of the broker.
The authorization profile that will be used to authenticate to the broker. To learn more, see Authentication in Kafka.
The mode in which the test step will operate: Publish or Subscribe.
The channel to which the test step will connect.
Allows linking the test step to another operation, thus changing the channel.
Opens the connection settings.
To learn specifics of using the Event-Driven test step for sending and receiving messages, see the following topics:
To check incoming messages (that is, events that the test step consumes from a topic), you use assertions:
|Assertions are only available in the Subscribe mode.|
Tip: To create complex verification conditions, you can organize assertions into assertion groups.This is particularly useful for the Event-Driven test step because one test step receives multiple messages. For example, you can add two JSONPath Match assertions to an assertion group and configure it so that the test step passes if either of those assertions passes.
You can filter the messages to show only those that either passed or failed a certain assertion. To do that, point to an assertion and select the needed option from the drop-down list.
|You can set a filter only for one assertion at a time.|
To delete the filter, click Clear:
|Contains||Verifies that the incoming message contains the specified string.|
|Equals||Verifies that some value in the incoming message is equal to the specified value.|
|JSONPath Count||Counts the occurrences of the specified JSON item.|
|JSONPath Existence Match||Checks whether the specified JSON item is present in the incoming message.|
|JSONPath Match||Checks whether the specified item in the incoming message matches an expected value.|
|JSONPath RegEx Match||Checks whether the specified item matches a regular expression.|
|Not Contains||Verifies that the incoming message does not contain the specified value.|
|Script Assertion||Executes a script to perform custom validation.|
While the test step editor is open, brief information on sent messages is listed in the Log tab. If the test step is run as part of a test case, you can see a more detailed log in the Transaction Log panel.