Data Driven Frameworks

The notion of a data driven automation tests is in itself a notion of grandeur. It is a highly commendable practice however what makes an actual data driven script?

The basic notion of a data driven script is one in which the data has been separated from the code. In its simplest form, a data driven script can be considered to be a simple case of centralizing the data in variables. The variables can occur in a group within the script and can be modified at need and in a central location.

The above notion is much the same as a tool vendor's concept of a data driven script. How much extra benefit is achieved by simply moving the data variables to an external file? Simpler interface. Maybe. Sure. Huge numbers of data variances for the same script. Not entirely. An array would provide the same features and would probably reduce execution time as well. Essentially the point of using an external data file is thus the simple interface that the file tool might provide.

Lets preclude my disillusionment and implement a data driven script in the above manner. It works wonderfully. Along comes an interface change. The changes require that 3 fields be added, 2 edits change to lists and 1 field is removed. Lets look at what the changes entail:

1. The data file is updated to include the new fields and remove the old fields. The new list entries are also updated to ensure that the correct items are selected
2. The GUI/object reference map is updated with the new objects and to update the edits to lists
3. The script code is updated to point to the additional fields. The function calls for the edits are changed to function calls for lists. The code for the removed field is commented out or deleted

But wait a bit. This is a data driven script. Why does the script code have to be updated? Surely a data-driven script precludes the necessity of having to modify code. I'd expect that to be the point of the exercise. So we'll call an implementation above, a pseudo data driven framework as it provides the illusion that the script is data driven.

So what makes a true data driven script. Quite simply a means of mapping the data parameters to the object references. The map will provide a means of identifying an object and its data value by a common reference. By following a simple object naming rule, its simple to identify the type of object being dealt with (for example, using "ed" in front of edit fields, "ls" in front of list fields). Using an object naming rule has drawbacks in terms of having to maintain the names. However, the automation tool may well provide a means of identifying the type of object through its internal mechanisms. If such is the case, then the naming scheme can focus on what it should focus on and that's the object's user name/purpose.

Having the object type means that the function needed for that object is immediately known. A function developed to take the type of object and perform the appropriate action simplifies the scripting. By parsing through the parameter list of a data file with an object to action function its possible to create a script as being purely data driven. In this environment the following changes would be required (using the same example)

1. The data file is updated to include the new fields and remove
   the old fields. The new list entries are also updated to ensure that
   the correct items are selected
2. The GUI/object reference map is updated with the new objects and to update the edits to lists

So it should be possible to only have to maintain data. Maintaining data is a lot less effort and less riskier than scripts.