How to write a good test case for Rasa chatbots?
Gather around, my children, as I explain how to write a test case with Rasa framework. Last time I have described some methods of testing chatbots in Rasa framework. You can find the article here:
How to test chatbots in Rasa framework?
Chatbots are everywhere so quality of the conversation they provide should be given increasing importance.
In the article, I have discussed testing stories, a method of testing dialogue flows. They are created like in Behaviour Driven Development. We describe the events we want to happen and check if they actually occurred.
Curesy of the author
This is the example of the story. The testing stories go to the directory called tests in the project folder. The test case consists of a descriptive name, in this case, “happy path 1”.
One of my university professors gave me the following advice, you should name your test cases indicating what the methods should return for instance shouldReturnTrue.
When we have created a perfect name for our test story, we have to create the dialogue flow with things the users say, the desired intent and action taken by the bot.
The previous example was simple and its purpose was to introduce the general steps of creating a test story in Rasa. Now to something more difficult and common.
Let us imagine we want to test a story for a restaurant recommendation bot. The user specifies the location and the type of cuisine he or she is interested in. Location and cuisine are entities because a user can provide many different locations or types of restaurants.
Taken from Rasa documentation
To test it, we have to specify the entity, in this case, Chinese, and surround it with square braces. After that, we have to state which entity “Chinese” belongs to (in this case cuisine) and encompass it with curly braces.
We can also test custom actions. Custom actions are the extra things your chatbot can do, like checking your balance or querying a database or API. You can write a method that does all those things underneath the hood.
Here is an example of such a custom action. As you can see, the action relies on slots. Slots assign variables, usually entities to serve as a short-term memory for a chatbot. In this case, we need city and type of cuisine to provide it to API.
The above story shows how slots can be tested. First, the chatbot asks about the city, the user is currently in, in this case, it is Lodz. Then the action_restaurants is called and the bot asks about the cuisine. The user specifies the cuisine as Italian so the action_restaurants_recommend returns information.
To sum it up:
- test stories are like test cases in BDD, we specify the behavior we want the bot to display
- test story consists of things the user has typed, a desired intent and action a chatbot takes like uttering some response or calling a custom action
- we can test entities by specifying to each particular entity the example belongs and slots while testing custom actions
- slots are the short term memory for bots; they can be used to query a database or call an API