Use module and shared module in testpartner to design a modular structure script

The main idea behind modular scripting to break up repeatable business functions or repeatable actions into the separate pieces which can be grouped together to run in compatible sets, but yet independently created and maintained. modules and shared modules, which are VBA assets used in testpartner that contain a declaration followed by a procedure, can be used tively in modular testing.

The difference between these two is simply in how they are implemented.

A module is available only to test scripts in its own project and must be explicitly encoded in a test script for it to be referenced or called. if a module is created in the common project then it can be explicitly encoded in any test script.

A shared module is implicitly encoded in all test scripts contained inside its own project. If it is created in the common project it, is implicitly encoded in all test scripts.

If creating shared modules in a common project, be aware that any name or word used in the shared module shocould not be used in a test script or function. this cocould cause compile errors that at first sight may not make sense. also, large numbers of shared modules in either the common project or another project add potentially unnecessary overhead to the test scripts being played back. this may create the potential for Memory Overrun issues.

Shared modules are best used as containers for a defined set of actions that are vital to testing, but shoshould be available for every visual test or test script. the best examples of this are error handling or statistic gathering.