To make testing your app easier (and annoy your developers and QA teams less), we made an App Simulator that you can use to walk through your entire application without deploying and testing live.

Installing the Simulator

The simulator is part of our SummitEditor package for Sublime Text 3. Package control is the easiest way to install, manage and use plugins for Sublime Text 3. Install Package Control, then in Sublime Text 3, use Ctrl + ⇧ + P (⌘+ ⇧ + P) to open the Command Panel, then start to type "Package Control : Install Package" and select it when it appears. When the list of available packages loads, start to type "Summit." Select SummitEditor to install.

Using the Simulator


In Sublime Text 3, go to File -> Open and select your app’s repo directory. Then, go to Project -> Save Project As… , name and save the project in the same directory.

Now that you have a project created, we need to add some simulator settings to it. Simply go to Project -> Edit Project and add the following:

"build_path": "/folder/that/contains/your/application/source"

build_path should point to the src directory's parent directory and not the src directory itself.

It should look something like this:

      "follow_symlinks": true,
      "path": "/folder/that/contains/your/application/source"
"build_path": "/folder/that/contains/your/application/source"

Now with all the .lua files in your project selected, go to View -> Syntax, and set the Syntax as Lua (Summit).

You can now simply press CTRL + B on Windows or Linux machines and ⌘ + B on Mac. This should cause a terminal window to open on your screen allowing you to interact with your simulated application.

NOTE: If the terminal window does not open, try the following: With all the .lua files in your project selected, go to Tools -> Build System and make sure "SummitEditor" is selected.

Using Datastore in the Simulator

To access data from your tables in Datastore, you will need to include some additional options in your project settings.

      "follow_symlinks": true,
      "path": "/folder/that/contains/your/application/source"
"build_path": "/folder/that/contains/your/application/source",
"application_id": "12345678-1234-5678-1234-567812345678",
"api_key": "vK8oVvsIOpXhFLmjjeiDKeilnl",
"api_secret": "kkjdshaf7dkk3*ljds093k^djk3",
"use_live_datastore": "true"

You can generate an API Key and Secret Key in your Summit Account under Access -> API Keys. Application IDs are available in the Applications grid. Hover over a column header and click the arrow that appears. You will see a menu with addition available columns, including "Application ID."

Run Options

You can set additional flags for your application before being run. Use CTRL + Shift + B on Windows or Linux machines and ⌘ + Shift + B on Mac. This will open an options panel on the bottom of the screen. The options panel accepts arguments prefixed with dashes and separated by spaces.

A complete list of options is as follows:

  • DNIS: Sets the DNIS or "number dialed", useful for testing number based routing. Example: --DNIS 5558675309
  • ANI: Sets the ANI or "number app called from", useful for doing things like looking up existing customers by phone number. Example: --ANI 5554441212
  • test: Run unit tests from your "spec" folder in the simulator. Example: --test
  • verbose: Should only be used in conjunction with test; This will output the full coverage report for your application (line by line), allowing you to see where you are missing test coverage. Example: --test --verbose
  • application_destination: Sets the application_destination for your application, just like if you used the field named "application_destination" on a routepoint or in a scheduled dial. Accessible in your app from the summit.application module, with the get_destination() command. Defaults to null.
  • application_data: Sets the application_data for your application, just like if you used the field named "application_data" on a routepoint or in a scheduled dial. This must be a string, but if you pass in a string which can be JSON decoded back into an object, we will decode it first and pass that object along to your application when you call get_data() from the summit.application module.

Example Use of Run Options:

--DNIS 5551230987 --ANI 5554445678 --application_destination 5559995544 --application_data '{"foo": {"bar": "baz"}}'

This application code can be used to see the results of the above set of arguments:

local application = require "summit.application"
print(  -- prints 5551230987
print(  -- prints 5554445678
print(application.get_destination())  -- prints 5559995544
print(application.get_data())  -- prints {"foo": {"bar": "baz"}}
print(application.get_data()  -- prints "baz"

Using the Debugger

We provide an interactive shell (Read-eval-print loop) that can be used for debugging. Simply drop repl() into your code to create a breakpoint, then run the simulator.

channel.say("Hello. Enter a number.")
x = channel.gather()

The simulator will pause at your first breakpoint. You can step through your code, use the "inspect" library to inspect variables, and more.

Type /help any time in the debugger to get a full list of options (below).

<statement>          -- execute a statement in the current context
/delallb             -- removes all breakpoints
/delallw             -- removes all watch expressions
/delb [line file]    -- removes a breakpoint
/delw <index>        -- removes the watch expression at index
/dump <var> [depth]  -- dump all fields of variable to depth
/exit                -- exits debugger, re-start it using pause()
/fenv [depth]        -- list context function env to depth, omitted=1
/glob [depth]        -- list globals to depth, omitted=1
/gotoo [line file]   -- step to line in file
/help [command]      -- show this list or help for command
/info                -- dumps the complete debug info captured
/listb               -- lists breakpoints
/listw               -- lists watch expressions
/locs                -- list all the locals names
/out [N]             -- run lines until stepped out of N functions
/over [N]            -- run next N lines, stepping over function calls
/poff                -- turn off pause() command
/pon                 -- turn on pause() command
/run                 -- run until next breakpoint or watch expression
/set [level]         -- set context to stack level, omitted=show
/setb [line file]    -- set a breakpoint to line/file
/setw <exp>          -- adds a new watch expression
/step [N]            -- run next N lines, stepping into function calls
/trace               -- dumps a stack trace
/tron [crl]          -- turn trace on for (c)alls, (r)etuns, (l)lines
/ups                 -- list all the upvalue names
/vars [depth]        -- list context locals to depth, omitted=1
/what <func>         -- show where <func> is defined (if known)