Skip to main content

Dialog set fields

A file with a dialog set must have the following fields:

Other fields in the file are ignored.

testCase​

The name of the test case that contains the step.

A test case can have several steps. In this case, specify the same value for the steps in the testCase field.

The test case steps are performed in the same order as in the file. If one of the steps is unsuccessful, the following steps are also considered unsuccessful and are not performed.

Example: a test case with several steps
testCasecommentrequestexpectedResponseexpectedStateskippreActions
weather/start/Start
weatherwell, helloHello there!/Hello
weatherWhat’s the weather?/Hello/Weather

The weather test case consists of three steps:

  1. The user says “/start”. Expected reaction: the bot transitions to the /Start state.
  2. The user says “well, hello”. Expected reaction: the bot transitions to the /Hello state and replies “Hello there!”.
  3. The user says “What’s the weather?”. Expected reaction: the bot transitions to the /Hello/Weather state.

If the field is not filled out, a random identifier is used.

comment​

Comment for the step. This field is optional.

request​

The user request that the bot will react to.

expectedResponse и expectedState​

Bot reaction:

  • expectedResponse is the expected text of bot’s response.
  • expectedState is the first state the bot must transition to. Specify the full path. The path must start with /.

A step must have at least one of these fields filled out.

Only filled fields are checked during the test. If the expected values match the received ones, the step is considered successful.

Several responses in a row​

The bot can give several responses in a row:

  • In one state:

    state: Hello
        a: Hello!
        a: How are you?

  • When transitioning between states:

    state: Hello
        a: Hello!
        go!: /Question

    state: Question
        a: How are you?

In these cases, specify responses in the expectedResponse field and separate them with a space: Hello! How are you?

Random responses​

The bot can give a random response:

state: Success
    random:
        a: Thanks for ordering!
        a: Order accepted!
        a: Thanks for buying!

To check a random response, provide all possible response variants. Specify each additional variant on a new line in the expectedResponse field and leave all other fields empty.

testCasecommentrequestexpectedResponseexpectedStateskippreActions
successbuyThanks for ordering!
Order accepted!
Thanks for buying!

The step is considered successful if the response matches one of the three phrases: “Thanks for ordering”, “Order accepted!” or “Thanks for buying!”.

tip

You can also use masks in each response variant.

Masks in responses​

A bot response text can be generated dynamically: for example, if the bot adds data received from an external system to the response. The full text of the response is not known in advance, because some parts of the response may change.

In these cases, you can use masks in the expectedResponse field:

MaskDescriptionExamples
{NUMBER}A sequence of digits.
  • 0123
  • 15
{WORD}A sequence that can contain letters, digits, and a hyphen (-).
  • Hello
  • GPT-3
{LINK}A URL address with the HTTP or HTTPS protocol. The address can contain Cyrillic characters.
{ANYTHING}A sequence of any characters. It consists of at least one character.
  • Hello there!
  • Abc123_!? ,.
note

To escape a mask, specify the \ symbol before the mask. Example: \{LINK}.

Mask use examples
expectedResponseText that matches the expectedResponse
Available days: {WORD}, {WORD}Available days: Monday, Thursday
Order number: ${NUMBER}. Follow the link: {LINK}Order number: 15. Follow the link: https://example.com
Your secret code: {ANYTHING}Your secret code: Abc123_!? ,.
Specify the number in the \{NUMBER} formatSpecify the number in the {NUMBER} format

skip​

The field determines whether the step is skipped.

Possible values: TRUE, FALSE (default). The value is case-insensitive.

If TRUE, the step is skipped and not checked.

preActions​

The name of the test case whose steps will be performed before the current step.

Steps from preActions:

  • are not checked and do not affect the test result;
  • are always performed, even if their skip field is set to TRUE.
Example of preActions usage
testCasecommentrequestexpectedResponseexpectedStateskippreActions
hello/start/Start
hellowell, helloHello there!/Hello
weatherWhat’s the weather?/Hello/Weatherhello
alarmSet an alarm/Hello/Alarmhello

To check the weather or set an alarm, the user must first say “/start” and “well, hello”. If you don’t want to add these steps to the weather and alarm test cases, you can specify them in the hello test case:

  1. The user says “/start”. Expected reaction: the bot transitions to the /Start state.
  2. The user says “well, hello”. Expected reaction: the bot transitions to the /Hello state and replies “Hello there!”.

You can now perform these steps before the weather and alarm test cases using the preActions field.

The weather test case:

  1. The preActions steps are performed:
    1. The user says “/start”.
    2. The user says “well, hello”.
  2. The user says “What’s the weather?”. Expected reaction: the bot transitions to the /Hello/Weather state.

The alarm test case:

  1. The preActions steps are performed:
    1. The user says “/start”.
    2. The user says “well, hello”.
  2. The user says “Set an alarm”. Expected reaction: the bot transitions to the /Hello/Alarm state.

This field is optional.