The Importance of Tool Independence in Test Automation
When my company first started to do test automation, one of our first steps in the implementation was to develop a strategy. We had one important constraint, though: independence from test tools.
I had already decided to adopt some kind of keyword-driven testing, but it is usually implemented with domain keywords that are written in the script language of the tool. This had two big disadvantages for us:
- We would be implementing a lot of domain knowledge into the tool itself
- We would not be able to use the keywords across our whole product palette because our software applications for insurances were very different in the content development environment
I finally came up with the idea to use simple commands as keywords, such as INPUT to edit some text in an edit field or SELECT,Button to click on a specified button. We called it command-driven testing.
Command-driven testing has proven to be a good way to implement the pattern TOOL INDEPENDENCE. (Note that at the time I had no idea that I was doing test automation patterns.) The main advantage is that you just have to develop the commands in the script language of the tool, and usually you don’t need more than thirty to fifty commands. To change tools, you only have to rewrite the keyword commands in the script language of the new tool.
Actually, you still need something else. Every tool automatically names the objects that it drives according to some cryptic algorithm. Of course, none is compatible with other tools. The trick, then, is to register all the objects with the tool by giving them recognizable names that will be used in your domain scripts (the ones using the command keywords).
Changing tools will force you to do this registration for the new tool, but having done it once, you will be able to use your domain scripts with no change. This is also a pattern. We called it OBJECT MAP, and it is likewise critical to reach tool independence.
What tools and patterns turn out to be the most useful depends on your company’s needs. But even if the above commands aren’t your fit, tool independence is a practical concept to keep in mind so you can be flexible according to your requirements.
