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