Xpectador 1.0

Xpectador is a command-line tool for verifying the content of XML-documents, any XML-documents. It's very easy to use, and requires almost zero learning.

Suppose we expect our XML document to have the following "profile":

<root>
<element_a attr_1="X">value_a</element_a>
<element_b>
<element_c>value_c</element_c>
</element_b>
</root>

What we would do is: save that expectation as an XML file, and executes Xpectador the following way:

xpectador my_expectation.xml document_tobe_verified.xml

That is all. In case xpectador finds that your document doesn't meet the expectation, it will exit with code -1, and print out some messages, such as: "Expected element could not be found: <element_b>...</element_b>". That will help you identify the issue in your document more quickly.

Note that I used the word "profile" instead of "content" because Xpectador performs more than simple text-comparisons.

It allows you to express the following expectations:

  • Positive expectation: I want to see this particular element that contains these attributes, etc.
  • Negative expectation: I don't want to see this particular element.
  • Don't care: I don't care whether the document contains this element or not.

The neat thing about Xpectador: you don't need to learn any new syntax (format). You state your expectations -- as XML document -- using the same format as the document that you want to verify.

You've seen the an example of "positive expectation" above. To state a "negative expectation", in the expectation file you only need to insert a special attribute in the element that you don't want to see. Example:

<root>
<element_b>
<element_c Expected="N">value_c</element_c>
</element_b>
</root>

That's a way of saying "I don't want to see element_c whose value is value_c, inside element_b". In case that expectation is not met, you will get the following message from the xpectador: "Non-expected element was found: <element_c>...</element_c>".

"Don't care"? Well, it's the easiest: just omit the element from your expectation document.

You can specify a different name for that special attribute. You do that by specifying the third in the execution of xpectador. Example:

xpectador my_expectation.xml document_tobe_verified.xml esperado

We'll, I guess that's all for the intro. There actually isn't much to talk about how-to-use this application due to its simplicity. However I know you will ask "can I trust the outcome?". That was also my concern, and I do have the list of test-cases for this application. I'll try to find a time sometime next week to be able to write a couple of things about it.

In the meantime, feel free to use it. Grab it from here (box.net). Just unzip the file, you'll find one EXE file in there (xpectador.exe). You will reap the real benefit of this kind of tool if you integrate it to your chain of automated-tests.

The source: http://www.box.net/shared/u55s51p9hf

Feel free to drop me an email if you have any question regarding this tool or in case you find anything that looks like a bug. My email: raka.angga@gmail.com.

Credits: this tool is written in Python, with a 3rd-party library for XML-processing (lxml), and compiled to EXE using py2exe..., on Vista :D

DB Conan 1.0

DB Conan is a data-retrieval tool. It's named after a manga character, Conan, kind of little Sherlock :).

This tool allows you to define a subset of the database that you're interested in (so you wouldn't be bogged down by unnecessary details / information overload during your testing / investigation activities). Once you have your subset-of-schema -- and some filters that you can also define -- set, you can load the data again and again, without typing any SQL query. This can potentially save your time.

The following slides provide a more detailed description of this application (download the PowerPoint file from Box.net):


The application itself is available on the following URL: http://www.box.net/shared/5ag8ja4eli

The source: https://github.com/rakamoviz/dbconan

Its current status is prototype. Anyway, it's usable; I'm already using it in my daily work. I hope you'll find it useful as well.

I do plan to further develop it (with GUI, etc), but only after I've finished my other project that has been pending for so long (a series of video on how to develop IMS application using SIP-Servlet and VoiceXML). Once I've finished it -- hopefully within this one month period -- I'll get back to this DB Conan. In the meantime, feel free to drop me some feedbacks / questions.

Quick showcase - demo EZ-IVR application

Hover your mouse over the video to see the thumbnails / shortcuts to the other videos in this series.

Troubleshooting: if you see "the video is no longer available" message, try to refresh this web page. Hope that solves the problem for you. Otherwise, you can go directly to the YouTube page here.

The images displayed in Part 1 in this video presentation can be downloaded from: http://www.box.net/shared/vkyu7w1s00

A friendlier-for-the-eyes version of this blog entry is available at the following URL: http://www.geocities.com/rakabali78/ezivr.html

This is a series in progress, more videos are coming up starting next month.

The following is the brief overview of each video in the series (so far):

Part 1 : Domain overview. In this part the (business) use of this application is explained. The domain model of this application is also explained here.

Part 2.a : Demo execution - intro. In this part the cases that will be demo-ed in the subsequent videos are explained.

Part 2.b : Demo execution - call transfers. For case 1 & 2, the call transfer is answered by the callee. For case 3 & 4, the call transfer is rejected by the callee.

Part.2.c : Demo execution - call transfer and queue. For case 1 & 2, the call transfer failed because the callee is busy, so the caller is asked whether she wants to wait in the queue. There's a timer for each element in the queue, that timeouts after a couple of seconds (45 in this demo), and checks the current position in the queue; if it's the 1 (the first) the call-transfer will be retried.

Part.2.d : Demo execution - call transfer and queue (two callers). It's the same as case 5, but with two callers. Here we verify that the positions are calculated correctly, and that the queue actually moves (so when the element that was first in the queue terminates the call, the element that directly followed it will move forward in the queue).

Part.2.e : Demo execution - play a message in the IVR. In the IVR tree you can configure some "messages node". The subscriber can use it to allow callers access announcements / advertisements through the IVR.

Part 3 : Brief development info. Here I explain briefly the modules that make up this application. I also explain the pattern that I employed when I implemented this application. Lastly, I glazed over some testing concerns & challenges.

Booklet: Telephony application development with Asterisk, Java, and SIP

The booklet takes you through the process of developing a simple telephony application made using the stuffs mentioned above. Along the way (I hope) you'll develop a firm basic understanding of those stuffs, and be ready for your further adventure in telecommunication application development.

Download the booklet (PDF, 5 Mb).
Download the source code of the application explained in the booklet (TarGz, 1.5 Mb).

Booklet: telephony application development using Asterisk, Java, and SIP Booklet: telephony application development using Asterisk, Java, and SIP raka.angga