Keyword-Driven Testing HOWTO Part 3 - Test Automation Engine "Handlers"

Today's article on KDT introduces a key concept for automating our keywords - handlers. In the previous article, Keyword-Driven Testing HOWTO Part 2 - Preparing The Keyword List For Automation, we finalized our keyword list and demonstrated their use in some preliminary test cases. Now we need to begin automating the keywords so that testers can begin writing and executing automated test cases without needing any programming skills.
To refresh our memories, here's the finalized keyword list:

• Calculator Run|Quit
• Select View Basic|Scientific|Programmer
• Paper Tape Show|Hide
• Calculate Operand1,Operand2,Operator,Result
• Window Calculator|Paper Tape,Minimize|Unminimize

Our job now is to write a handle for each of these keywords so that the test cases we discussed in the previous article, like the one below, will make sense to the automation test engine.

1. Perform calculation using the Basic calculator without using paper tape.

• Calculator Run
• SelectView Basic
• PaperTape Hide
• Calculate 10,20,X,200

But first we'll need to understand the concept of a handler and what it looks like to program one. And has I mentioned in the first KDT article, Using Keyword-Driven Testing To Understand The Benefits of Model-Based Testing (MBT), we're going to program our handlers in AppleScript. If we had chosen Visual Basic Script or some other language, we would probably implement our handlers as part of a CASE statement. But for Applescript, handlers are a fundamental part of the language, hence we won't need to add anything to our automation engine to make them work.

A handler in Applescript, as described in the AppleScript Language guide, is:

"...a collection of statements that can be invoked by name. Handlers are useful in scripts that perform the same action in more than one place. You can package statements that perform a specific task as a handler, give it a descriptive name, and call it from anywhere in the script. This makes the script shorter and easier to maintain. The definition for a handler specifies the parameters it uses, if any."

That's a perfect fit for what we intend to do with KDT: we're going to refer to things by specific names (our keywords) and, in some case, pass parameters along with the name, e.g. Calculator Run. And what's cool about AppleScript and how it employs handlers, is the way in which you call upon these handlers to do something. You simply type a handler's name and any parameters and the handler goes to work. Here's an example of handler that speaks any word you send it:

on speak(this)
   say this
end speak

and the way you call upon this handler to do its job is simply:

speak("Hello")

As you can see from this example, the handler's name is "speak" and the parameter you pass it is what you want to have spoken, in this case "Hello". Here's the Applescript code that includes both the invocation of the handler and the handler itself:

speak("Ray")

on speak(this)
   say this
end speak

So you can think of the "speak" handler as representing a keyword in our KDT dictionary and speak("Ray") as a test case. In next week's article I'll reveal each AppleScript handler needed for our dictionary and convert the sample test cases to work with the those handlers.