Unit Testing for Voice Apps

To make sure your Alexa Skills and Google Actions are robust, we highly recommend testing. Learn how to implement unit tests for your voice apps built with Jovo.

• Introduction to Unit Testing
• Getting Started with the Jovo TestSuite
  • Install Jest
  • Create Test File
  • Run Test Script
• Basic Concepts
  • Conversation
  • Request
  • Response
  • Check
• Advanced Concepts
  • i18n Keys
  • User Data

Introduction to Unit Testing

Unit Testing is a testing method that allows you to make sure individual units of software work as expected. This way you don't have to manually test every potential interaction of your voice app after any change you do to the code, which not only saves a lot of time, but also gives you some well deserved peace of mind.

The Jovo TestSuite allows you to create unit tests for your Alexa Skills and Google Actions that can either test certain individual features, or even full conversational sequences.

Getting Started with the Jovo TestSuite

Use the Jovo Unit Testing Template to get started with some first tests.

Here's everything you need to know to get started:

• Install Jest
• Create Test File
• Run Test Script

Install Jest

Since Jovo v2, every new Jovo project comes with Jest as dev dependency and sample tests.

The Jovo TestSuite builds on top of Jest, a popular Javascript testing framework.

You can add Jest as dev dependencies like this:

Create Test File

You can find an example test project here for Typescript. Javascript Here.

Unit tests are usually located in a test folder of your Jovo project. Naming conventions are <name>.test.js.

This is how a sample sample.test.js file with a single test for both Amazon Alexa and Google Assistant could look like:

Run Test Script

After you've defined some first tests, add the following script to your package.json:

This way, you can run the tests with npm test. Don't forget to first start the Jovo webhook:

Basic Concepts

Tests can be run for each platform:

After initializing the TestSuite, you can add test groups like this:

Each test contains the following elements:

• Conversation
• Request
• Response
• Check

Conversation

Each test starts with a conversation:

Conversation Configuration

You can also add certain configurations to the constructor of your conversation object.

Here are the configuration options:

Here is a list of the default configurations of the conversation object:

Request

Request Builder

You can use the request builder of the testSuite to build a request. The following request types are supported:

• launch
• intent

After creating a request with the request builder, you can modify with several helper methods:

Find out more about the helper methods for the Jovo $request object here.

Response

The previously created requests can be sent to the conversation. This will then return a response:

You can then used these responses to compare them to expected results (see section Check below):

Find out more about the helper methods for the Jovo $response object here.

Check

Learn more about Jest Expect here.

Advanced Concepts

For more thorough testing, you can use the following advanced concepts:

• i18n Keys
• User Data

i18n Keys

When you're using the Jovo i18n or CMS integrations, you might not want to make checks with strings like 'Hello World! What\'s your name?' as in the examples above, as the i18n content could change, use different variations, and languages (locales).

The solution for this is to configure the conversation in a way that the CMS only returns the i18n keys instead of strings (values), which can later be checked against expected keys.

You can do this by setting the locale of the conversation to a random string, for example keys-only, in the conversation configuration:

For example, if you used this.t('key') in your app logic and now set the conversation locale to keys-only, the getSpeech() method of the unit test would (if correct) return only key instead of the string (value) stored in the CMS.

You can then use the Jest toMatch method to match it to an expected key:

If your output uses several chained keys (for example by using the SpeechBuild addT method), you can add them together like this:

User Data

You can use the conversation to store and retrieve user specific data as well as you would using the Jovo User object:

As unit tests are run locally, this will save the data into the default FileDB database.

This also allows you to access User Meta Data:

You can also delete the database for this user with the following method: