I have a web testing framework build with vbscript classes. It has been reliably used multiple times and incorporates multiple features for logging, runtime properties, project initialization etc.
What are some ways to identify if any module would be suitable to be moved to a script extension?
Alumni
djadhav wrote:
What are some ways to identify if any module would be suitable to be moved to a script extension?
Technically, code can be moved to a script extension if it uses objects and methods supported in extensions. For example, the ADO and DDT objects work in extensions, but TestedApps is not available there. Also, some TestComplete global constants like pmNormal or cmpMatches need to be explicitly defined in extensions.
Champion Level 3One more thing to consider:
When the functionality is in the regular script unit and this unit is included in the test project, the one gets access to this functionality as soon as he/she opens the project. When the functionality is moved to the script extension, this extension must be deployed to every new workstation that is planned to be used to work with the project that uses this script extension.
My entire framework consists of Script Extensions and a single Script unit (Driver).
For me, anything that is project-agnostic, and/or forms part of the framework (framework should always be project-agnostic), ends up in a Script Extension.
All the Script Extension code is stored in their own version controlled own project.
I take the point that you then need to update any new installs with the extensions, but if you have multiple project suites running common code then your only other option is to have a shared project that they all use. Which doesn't work for me as my office runs several internal networks that can't all see each other so I can't simply reference a single centrally stored project.
Plus, it also sends to be extensions (new functionality), rather than fixes, that get applied to the extensions projects. They have all been in use for several years now and ar every stable. Older projects, which don't use some of the newer functionality in the script extensions, simply don't call them. They didn't exist when the project was created so the project contains no references to them.
If something is subject to frequent change, or is not yet stable, then script script extensions may not be the best idea.
Once you move tests to extentions it's cumbersome to debug or change
so my suggetion is to move very stable part of the code
i.e. you are sure those need not be change in future and established bug free.
also high reusebility -eg other testers are going to benifit from your extentions
