Testing Localization

You may recall that every one of the BST test specifications we’ve written have started with a configuration block that includes a locales property:

Up until now, we’ve only been working with U.S. English, so the locales property in all of our test specifications has been set to “en-US”. But now that we’re ready to test for other locales, we will set it so that our tests will cover all of the new locales and languages we’ve extended our skill to support. That’s easily done by listing all locales you want to test for, comma-delimited in the locales property.

For example, here’s the specification that tests the launch request for an authorized user:

When this specification is run, each of its tests (in this case, there’s only one) will be run once for each locale listed in locales. Given the locales we’re testing for, the “Launch request” test will be run eight times, each time for a different locale, but asserting the same response.

The problem, however, is that the SSML assertion is in English while three of the eight locales listed are Spanish. That means that it will fail three times when the Spanish response doesn’t match the English assertion.

Fortunately, we can extract assertion messages from our tests in a way similar to how we extract the spoken test strings in our fulfillment code. All we need to do is create a new locales directory under the test directory and create YAML files for each language that will hold the assertion messages. To get started, here’s the English-specific assertions file:

The file is named en.yml to indicate that it contains English strings that we’ll use in our tests. If our strings differed for the individual English locales, we could be more locale-specific by naming it en-US.yml and creating different files for en-GB.yml, en-CA.yml, and the other English-speaking locales. But a single file for English strings is fine for our needs.

Similarly, we can create a file of Spanish strings in es.yml:

Now that we’ve extracted the assertion string into separate language-specific files, we can use it in our test by replacing the assertion string with the name “welcomeMessagePersonal”:

By applying this same technique to all of our tests, we can add multi-locale test coverage to our skill. For now, though, let’s run the launch-request-authorized.yml spec to see if it works:

Awesome! As you can see, the “LaunchRequest” test ran eight times, once for each of our supported locales. And, what’s more, they all passed!

Although we could rest happy knowing that our localization work passes the tests, this is one of those cases where it’s better to hear what Alexa says and not just trust that she says it correctly. So let’s take a moment and make sure that she not only speaks Spanish responses, but also pronounces them correctly.