"We should focus our automation framework to deal with the common components that make up our unique applications."
Nearly all applications come with some form of menu system. They
also have buttons to push, boxes to check, lists to view, and so on. In
a typical automation tool script there is, generally, a very small
number of component functions for each type of component. These
functions work with the component objects independent of the
applications that contain them.
Traditional, captured automation scripts are filled with thousands
of calls to these component functions. So the tools already exist to
achieve application independence. The problem is, most of these scripts
construct the function calls using application-specific, hard coded
values. This immediately reduces their effectiveness as
application-independent constructs. Furthermore, the functions by
themselves are prone to failure unless a very specific application
state or synchronization exists at the time they are executed. There is
little error correction or prevention built-in to these functions.
To deal with this in traditional scripts we must place additional
code before and\or after the command, or a set of commands, to insure
the proper application state and synchronization is maintained. We need
to make sure our window has the current focus. We need to make sure the
component we want to select, or press, or edit exists and is in the
proper state. Only then can we perform the desired operation and
separately verify the result of our actions.
For maximum robustness, we would have to code these state and
synchronization tests for every component function call in our scripts.
Realistically, we could never afford to do this. It would make the
scripts huge, nearly unreadable, and difficult to maintain. Yet, where
we forego this extra effort, we increase the possibility of script
failure.
What we must do is develop a truly application-independent framework
for these component functions. This will allow us to implement that
extra effort just once, and execute it for every call to any component
function. This framework should handle all the details of insuring we
have the correct window, verifying the element of interest is in the
proper state, doing something with that element, and logging the
success or failure of the entire activity.
We do this by using variables, and providing application-specific
data to our application-independent framework. In essence, we will
provide our completed test designs as executable input into our
automation framework.
Does this mean that we will never have to develop
application-specific test scripts? Of course not. However, if we can
limit our application-specific test scripts to some small percentage,
while reusing the best features of our automation framework, we will
reap the rewards project after project.
click here for more details:
http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm - http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm