What You Should be Aware of When Using Script Extensions

Artboard 2

Developing an automated test suite in TestComplete occasionally requires the test developer to create global variables, libraries of commonly used functions, and classes that will be used in many different scenarios. Within a single project, this is easily handled in various ways depending upon the scripting language being used within the project. For example, a uses clause at the beginning of a DelphiScript unit would contain the names of all the units of code that would be used by the new unit. USEUNIT is available for most code languages. JavaScript uses the modules.export to export methods to be used in other units, referenced by the requires method. And Python uses import to import modules and units into other Python units.

However, the larger a project gets, the more cumbersome this can get. Each new unit of code that needs to use those common objects needs to have these lines added to it. And, as the library of common code objects increases, those import, requires, export, USEUNIT, etc., sections of the rest of the code will continue to expand. Maintaining this web of referenced code can become a consuming task. For that matter, debugging a problem in one of the library functions means tracing back through the call stack to find out where the call came from to determine if there was a problem early in the stack.

One other challenge presents itself if you have multiple projects in a test suite, each of which needs to use the library code. This is not an impossible thing to overcome. Simply add the unit to the new project by adding it as an existing item, essentially sharing the code between projects. However, what this means is that any dependencies that a unit references would also need to be added, again, presenting the problem of having to maintain a broad web of referenced functions and units.

Essentially, there are two things that would make this part of developing an automated suite easier. If the various common functions, methods, and objects could be compiled into the TestComplete environment in a way that can be called from any script unit or keyword test without needing to add them to a project or use any of the methods for referencing them in an additional code unit, this would make maintaining those dependencies and code references much easier. Additionally, reducing the call stack to a minimum would make debugging problem code easier by reducing the amount of tracing that needs to be done.

TestComplete does have the benefit of being a COM-based architecture. One method of doing so is using the TestComplete SDK to create COM-based custom plugins to extend TestComplete to fit custom needs. However, doing so requires either Visual Studio or Delphi with the experience and knowhow of creating such things.  While many automated testers come from a development background, not everyone doing test automation has that level of experience.

If, however, the tester has experience writing script code, then they can still create extensions for TestComplete. Specifically, if you know how to write VBScript or JScript, you can add runtime objects, new keyword test operations, record-time and design-time actions, and even custom actions on the test result logs. These script extensions can be written either in the TestComplete environment itself or using a simple text editor like Notepad.

As an example, take the necessity of running SQL queries against a database. The database could be the data accessed by the application under test or it could be a database used for a data-driven framework. Either way, writing a common function library of SQL methods and commands is a common task for many automated test developers. Instead of a code library that is imported into every project and added to every unit, a Runtime object can be created via a script extension where the various SQL methods would be available immediately within every code unit. Additionally, such a runtime object can be called natively from keyword tests without having to use a Run Script Routine test action.

This is just one example of how a script extension can help in test development. Another would be where the code for an automation framework could be encapsulated into a script extension so that it can be used for any project and any application under test. A script extension could provide custom log outputs to HTML or XML by making the logging methods part of the TestComplete environment. Custom checkpoint code can be created to specific needs of the application under test. Or, simply, the script extension could contain all the global variables that a testing project would use.

In the upcoming TestComplete 301 class that I’m helping to host, I’ll be walking through the process of creating a script extension for executing some common functions within a larger project. Please join me in learning how this powerful feature can go towards making automated testing a lot easier to maintain. Register here to sign up.

-Brought to you by SmartBear Academy.

Have future topics you would like to have us cover in a SmartBear Academy class? Let us know @SmartBear!

RedditFacebookTwitterGoogle+Hacker NewsLinkedInEmailPinterestShare

Speak Your Mind