DSL for workflow testing

Typically a QA tests the following in a BPM Application Portal.

* Logins into Portal
* Searches for tasks based on some artifact keys.
* Saves/Completes some assigned tasks.
* Creates tasks
* Waits for some tasks.

These are the few of the many items that a tester or a Business Analyst does, not necessarily in the same order except for the first item.

Now the DSL which is to be built abstracts only high level tasks that the user performs and gives the ability to the user to write his own scenario for automated testing.

For example, if the user wants to search a task, create an artifact like Payroll and then complete the task, he would simply write as,

login_into_portal_as_user(prasanna)
tasks[] = search_for_ID(100, ‘Assigned’, ‘Available’)
iterate all tasks
if task is ‘Payroll’
create_HRA (100, current_date, hra_amount, employee_details)
complete.task
end

The above DSL code is very granular, but with further analysis and level of testing required we can build the DSL functions at coarse grained level, which would limit and simplify the number of lines a tester/user have to use to build scenarios.

One of the objectives for building custom DSL is that anybody from non developer community can write test case scenarios making use of DSL. The above mentioned syntaxes are just examples and can be made much simpler or close to readable English.

I believe this can definitely complement performance testing tools as well. The DSL testing code need not be in the above format; even as XML would do and having DSL on top of any other workflow testing tool means that the services alone will be tested for functionality.

But when I thought about DSL for testing my intention was to use it at a UI level which would better comprehend what an actual tester does. Web flow / UI Level automated testing comes with some disadvantages too, due to the fact that DSL objects are highly dependent on HTML source.

DSL’s are evolutionary and the functionality that have to be tested using DSL should be built brick by brick. Dynamic scripting languages are good candidates for building DSL, reason being faster development time opposed to using a high level language. I was looking at Ruby + ‘Watir’ (pronounced as water and is a Ruby gem) for building a DSL with automated UI level test scripts.