In recent years, many software testers have chosen to adopt a “Keyword Driven” approach to test automation (sometimes also called “action words”, “test frameworks”, or “third-generation test automation”). In this approach, test cases are not defined directly in scripts, but in a simplified table format. Typically, each row in the table contains a keyword and associated parameters. So a table might look something like this:
launch SuperApp
verify SAMainScreen
login joeuser secretPassword
verify loginSucceeded
logout
Here, the keywords are launch, verify, login, and logout, but they could be any actions relevant to your testing context. The parameters are specific to each keyword, but might be image names or text to be typed and so forth.
One of the main reasons for adopting this approach is that it provides a fairly high-level, abstract representation of the steps to be taken to validate some functionality, without specifying the low-level details of how to carry out each of those actions. This makes it possible to specify a test before an application is fully functional and ready to be tested. The actual implementation of the scripts to carry out each keyword action can be developed later and can be changed over time to match changes in the application without having to change the test description in the table.
Some organizations also like this approach because it allows tests to be created by non-programmers, using a familiar tool such as a spreadsheet to create the table.
The suite presented here provides a foundation that shows one possible way to implement keyword driven testing in Eggplant. There is actually very little code involved. The KeywordDriver script provides the keywords and parameters, and calls the executeKeywords handler, which contains all of the interesting code.
The other scripts in the suite (launch.script, login.script, logout.script, and verify.script) are merely placeholders in this example that define the implementation of the keywords. To create your own keyword driven framework you would simply provide your own scripts to handle these or other keywords that are relevant in your test environment.
For those who like to look before they try, here is the complete executeKeywords handler:
to executeKeywords sourceText
-- get the list of valid keywords and display it
set validCommands to the short name of \
each item of the files of my folder \
where each ends with ".script" and each is not my name
put validCommands, "- - -"
-- process all of the source keywords and parameters
repeat with each line sourceLine of sourceText
put sourceLine split by comma into (command, paramList...)
if command is not in validCommands then
logError "Invalid Keyword: " & command
else
try
-- run the command; pass paramList as individual params
run command paramList as parameters
catch
logError "Error running " & command && paramList \
& ": " & the exception
end try
end if
end repeat
end executeKeywords