question

No, because once you're at the point where you're actually using your physical Echo, you're basically in a production environment. To debug your code, you should set up a testing framework and build tons of fake requests to run through your code, and do all of that in your local dev environment before you ever upload to your webserver. (And then build in some tests with requests that don't match the official format, to ensure you have edge case covering for unexpected Echo behavior.)

Thanks Greg. Hopefully Amazon will release a local emulator one of these days that we can use for live debugging. Until then, your approach makes the most sense.

There really isn't a need for a local emulator, IMO. Your functions should accept JSON and return JSON. That is completely testable by itself, independent of any web server or Alexa service. Hooking up the actual call from the Echo to your endpoint is trivial and doesn't need to be tested for each app, since it's just integration. The alexa-app framework I've built for Node.js allows developers to build stand-alone modules that accept and return JSON, and I've found it simple to write exhaustive unit tests for skills that use it.

Thanks Matt. What you are saying makes sense, though I would hate to have to write a unit test just to debug a specific issue or to be able to test ideas during primary development. I would have thought, for example, that if I could put a breakpoint at the appropriate spot in the code there might be places where I could see what Alexa heard. I don't see how this scenario would be unit-testable; that is, if I put into a text-based unit test what I *expect* Alexa to hear, that doesn't help me resolve what she is hearing when I verbalize the same phrase and she doesn't understand it. I realize that I can see what Alexa heard in the companion app, but I don't think this is as effective as a traditional debug session would be. Thanks again for your thoughts.