Mocking your skill backend with APL Ninja

Today I am very happy to announce the new mocking feature (beta) on apl.ninja. With the mocking feature you can easily simulate your skill responses in the editor.

Nowadays, an APL document can be tested almost completely in the Authoring Tool or in the APL Ninja Editor. However, if you want to test the integration of dynamic data sources or the interaction between the skill backend and the APL document, you need to switch to the Skill Simulator and have a working skill backend.

With the new mocking feature, this switch is no longer necessary and you can simulate the directives that your skill backend would send.

How it works

I have an APL document that uses both an index- and a token-based dynamic datasource.

Dynamic datasources are great for lazy loading of large datasets.

As the user scrolls through the list, Alexa sends your skill either LoadIndexListData or LoadTokenListData requests depending on the type to ask for more items to display. Learn more about the requests Alexa sends here. This request is displayed at the bottom right of the screen.

So far, I have not been able to test my APL document further than "item 41" (my last item in my datasource) without a working skill backend.

Let's define a mock

In a nutshell:

I have configured a token-based data source for my APL document and know that Alexa will send a LoadTokenListData request to ask for more items to display.

{
  "data": {
    "type": "dynamicTokenList",
    "listId": "foo",
    "pageToken": "foo",
    "forwardPageToken": "baz",
    "items": [
      {
        "primaryText": "item 1"
      },
      {
        "primaryText": "item 2"
      },
      {
        "primaryText": "item 3"
      },
      ... and many more items
    ]
  }
}

And the documentation tells me which parameters are sent in the request.

Since not all parameters are relevant for my mock and some are not available, I define the incoming request as follows:

{
  "type": "Alexa.Presentation.APL.LoadTokenListData",
  "listId": "foo",
  "pageToken": "baz"
}

The pageToken property refers to the forwardPageToken property in my data source.

The documentation also tells me that I may only respond to a LoadTokenListData with a SendTokenListData directive.

In my mocked response, I define a SendTokenListData directive as follows:

{
  "type": "Alexa.Presentation.APL.SendTokenListData",
  "listId": "foo",
  "pageToken": "baz",
  "nextPageToken": "bar",
  "items": [
    {
      "primaryText": "lazy item 1"
    },
    {
      "primaryText": "lazy item 2"
    },
    {
      "primaryText": "lazy item 3"
    },
    {
      "primaryText": "lazy item 4"
    },
    ... and many more items
  ]
}

As you can see in the screenshot I have created many more mocks for my document.

After defining my mock and scrolling through my list again, I see that both the request was sent and my mock was applied and my list no longer stops at "item 41" but scrolls much further.

With the mocking feature all kinds of requests and directives can be simulated. Another advantage is that you can see errors that occur when processing a directive in the APL core.

My directive falsely sends 2 times the same version for a list which leads to an error in the APL core.

At this point I would like to mention that this and other features would not have been possible without the great work of the team behind the APL Viewhost Web.

Take a look at the sample document to see the mocks in action.

Well, that's it. Have fun mocking your skill backend in your APL documents! If you liked the post, leave a comment and ❤️.