-
Notifications
You must be signed in to change notification settings - Fork 0
Implementation Notes
The messages defined in the Chorus client protocol allow a connected client to publish the steps it supports, and then have these steps executed as part of a Chorus test scenario
These are JSON messages which are sent over a Web Socket connection established between the Chorus client and the Chorus interpreter (or Chorus step registry)
In general the sequence of messages after an initial connection should be as follows
| Sender | Message | Cardinality | Description |
|---|---|---|---|
| Client | CONNECT | 1 | Announce the connection and send a client id and description |
| Client | PUBLISH_STEP | 1..n | Publish the details of a Step which can be invoked |
| Client | STEPS_ALIGNED | 1 | Inform Chorus all steps have been published. The Chrous interpreter may wait until receiving this message before starting test scenarios |
1 to n of:
| Sender | Message | Cardinality | Description |
|---|---|---|---|
| Interpreter | EXECUTE_STEP | 1 | Tell the client to execute a step |
| either.. | |||
| Client | STEP_SUCCEEDED | 1 | Tell the interpreter step PASSED |
| or.. | |||
| Client | STEP_FAILED | 1 | Tell the interpreter step FAILED |
In general it's expected that only one Chorus interpreter will execute steps on a connected client at a time, and that steps will not be executed concurrently
The Chorus interpreter sends a timeout period in seconds along with the EXECUTE_STEP message If no response is received in this time, the interpreter will fail the step, and fail the scenario with any subsequent steps skipped
Since this is distributed testing there are latencies involved, and some steps which check or assert pass/fail conditions may need to be allowed some time to succeed
When publishing a step, the client can configure certain steps (generally those which assert conditions which may fail due to latencies) to have a 'retry' period. This is done by sending a > 0 'retryDuration' in the PUBLISH_STEP message.
If a retry duration is specified, this operates in the following manner - First the interpreter sends the client an initial EXECUTE_STEP, and at this point the retry period is deemed to have started. During the retry period, any STEP_FAILED sent back to the interpreter by the client will be ignored, and an additional execution / re-run of the step will be requested by sending a new EXECUTE_STEP request after a small delay (the retryInterval). This will continue until either the retry period expires, or the client returns a STEP_SUCCEEDED.
If no STEP_SUCCEEDED is sent before the retry period expires, then the interpreter will consider the step has timed out, and will fail the step using the STEP_FAILED details which it last received from the client
Using the retry mechanism can simplify implementing the client step logic, since no blocking/waiting is required client side - with a retry set the client can simply check the conditions and pass/fail as appropriate within the period.
It is also possible for a client to implement it's own waiting for a condition to be satisfied. The interpreter will wait for a result message to come back until the timeout period specified in the EXECUTE_STEP message has expired. If at this point no STEP_FAILED or STEP_SUCCEEDED has been sent back to the interpreter, the interpreter will fail the step.