|Information in this topic applies to desktop and web applications.|
TestComplete includes several objects and events that let you manage the network suite and control distributed testing from script code or from keyword tests. This allows the master project to implement more complex logic for executing tasks and jobs than the logic of normal, top-to-bottom running. For instance, you can check the job or task state, change the job’s order according to specific conditions and perform other actions.
For each network suite element there is an appropriate program object:
NetworkSuite. Properties of these objects let you control the same element properties that you can modify via the TestComplete user interface. The
NetworkSuite objects contain the
Run method that initiates the execution of a task, job or network suite.
|You can use the
Checking Network Suite States
When a task, job, the entire network suite or the current project is running, its state goes through the following cycle: Idle -> Initializing -> Running -> Idle. During a task’s or the current project’s run there can be additional states: Waiting for CS, Running in CS, Synchronizing and others (see Network Suite States). Each of the
NetworkSuite objects contains the
WaitForState method, which delays script or keyword test execution until the object reaches the desired state, or until the time-out specified by one of the method parameters is over. There are also specific events that let you perform specific actions in response to changes in the object’s state:
Exchanging Data and Synchronizing Projects
To exchange data between projects that take part in distributed testing, you can use network suite variables. These variables are shared among all projects that participate in testing. That is, if one of the projects changes a network suite variable, other projects will use the new value. For more information about these variables, see Network Suite Variables - Overview.
Network suite variables are an efficient means for synchronization of two or more projects. They can work like semaphores: for instance, one project can store 0 to a variable and wait until another project changes the variable to 1. In addition, there is the
NetworkSuite.WaitForNetVarChange method, which allows you to suspend test execution until an appropriate network suite variable changes its value in the expected way. Finally, there is the
OnNetVarChange event, which occurs when a variable gets changed. You can handle this event in your scripts.
Other synchronization instruments are critical sections and synchronization points.
By using synchronization points (or synchpoints), you can make the project suspend its execution at the given synchpoint and resume it once other projects have reached their synchpoints with the same name. To do this, insert a call to the
NetworkSuite.Synchronize method in the appropriate location in the script code or keyword test and pass the method the name of the desired synchpoint. See Synchronization Points for more information.
With critical sections you can ensure that only one project executes a critical part of code at a given point in time (for instance, work with a file or some other critical resource). Once a project enters a critical section, other projects cannot enter the section of the same name and wait until that project exits the section. To enter and exit critical sections in your code, use the