• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Unit testing Voice (vxml) applications

 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi! I own and love your book "The Pragmatic Programmer". Although I am a total believer in unit test cases, I constantly find myself in situations where I don't know how to go about unit testing. So, I just code the whole kit'n'caboodle and then run it from start to finish. As you well know, this is not nearly so much fun as coding a little and testing a little. And it can be very frustrating.
Let me explain my current assignment. After spending three years working on a tightly coupled C++ client server app with an antiquated GUI tool I find myself on a team of folks developing VoiceXML applications for Interactive Voice Response systems -- the new generation of "Press 1 if you want this, press 2 if you want that".
All of us are new to the technology involved, not only is the VXML new, but the whole web component paradigm that drives it is new. It is very similar to web component development (as far as I can tell based upon my reading) but instead of interacting with a web browser such as Internet Explorer, the "presentation" piece of the application is handled by vxml as rendered by a "voice browser".
I looked at jWebUnit and found it rather complicated. When I considered translating the web browser concepts to the voice browser I became overwhelmed and fell back into "code it until it is finished" mode. Don't tell anyone because I would hate to admit that I am not unit testing my code.
Any advice for someone who wants to "do right" but who is just overwhelmed with all the little pieces (VXML files, JSP, Java utility classes)???
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I can see why you're overwhelmed -- there probably isn't a unit testing library for VoiceXML (hint to anyone interested ) which makes it that much bigger a step to automate testing these applications. However, what happens behind that VoiceXML interface is eventually plain old Java! You should consider whether you could unit test those little pieces that build up the whole.
 
Author
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To some extent, I can answer this question the same way I'd answer someone who wanted to test their HTML generation: build as think a presentation layer as possible, and then test up to that interface. That helps with the generation side, but VXML then has all that logic built into the pages themselves.
I've read of some folks who use Javascript in their VXML pages to simulate the transactions, and then test based on that. That seems a tad hard for my liking. I guess ultimately I'd suggesting keeping the on-page logic as transparent as possible, and then unit testing the code behind it, but not necessaryily the page itself.
Sorry I can't give a better answer: some technologies weren't designed with testing in mind.

Dave
 
Robin Clark
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, you've got that right.
From a performance perspective, you want to put as much functionality as possible on the client side -- this means putting lots of ECMA script in the very odd VXML code. This reduces the number of times that you have to go to the server, therefore response time is improved.
From a testing/aesthetic perspective, you want to put as much functionality as possible on the server side. This improves modularity, makes it easier to test, and is just plain prettier.
Thanks for your thoughts. I am going to buy your book for sure!
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My first time posting here, so a quick related advert. If you have a corporate testing budget for test tools, check out my company's VoiceXML testing tool: Voiyager at www.Voiyager.com. While not obvious in most of the online material, it has a full Java and .Net API that can be used to drive code level tests through a VoiceXML call flow. It's main purpose is to automatically explore and test. I'm very much in the CI (Continuous Integration) world, so I find the API to be incredibly powerful, but it doesn't play to the marketing message. I am the products development manager and architect.

As for some advice that doesn't involve buying things:
With VoiceXML, there isn't an easy free way to do end to end system testing. HTTPUnit and the like will let you drive the HTTP requests, but validating the responses other than a simple automated spot check isn't going to be very easy. Since there isn't an easy answer, as suggested above, divide and conquer.

Business logic: If in the browser, isolate your ECMAScript so that it can be tested with those frameworks. If server side (e.g. Java), again, isolate so that you can use existing test frameworks.
Host interfaces: This is probably server side or using VoiceXML's data or script element. In any case, server side code should be isolated to test with normal test frameworks (JUnit) or HTTPUnit (for Data elements)

If you've done the work above, you can take a broader stroke with the VoiceXML as you've reduced a lot of the common failure points that won't be caught with traditional manual testing. Using HTTPUnit with VoiceXML can be done. Perform some spot checks on form names, audio clip names and the like. A good VoiceXML generation tool or code framework will hopefully be plumbed with either <log> or comment blocks that you can use as landmarks to insure the flow is moving correctly. Additionally, you could write a VoiceXML to test your voiceXML application. To keep the call flows in sync, replace out key landmarking soundclips with recordings of DTMF tones that can be easily detected with your scripts (this technique may not work in some VoIP configurations because tones are no longer in band audio sounds, but out of band signaling messages).

I hope this response has been helpful and not just spam.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim,
Welcome to JavaRanch!

While sharing information about a product someone directly asks about is fine, please don't bump old posts. This question is four years old. It's unlikely the author still has this problem.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic