Synchronizing Projects - Overview

Synchronization Points

Network Suite Variables

Special Methods and Events

Critical Sections

Synchronization points are used to ensure that several projects simultaneously resume execution from a specified point in their script code or keyword test. This can be used to run an important section of script code or keyword test at the same time on several machines and thus emulate a real-time workload on the server application being tested.

For more information on how to set synchronization points and how to synchronize the execution of different projects, see Synchronization Points.

Network suite variables (also called NetSuite variables) are used for exchanging data between all of the projects that participate in distributed testing. This is possible because these variables are shared between the projects (it does not matter if the project is master or slave) and if one project changes a network suite variable, the others will use the new value.

You can also use these variables to synchronize projects during the network suite run. For example, you can delay execution of the projects until a specified network suite variable gets a desired value. For more information on how to control changing a network suite variable value, see below.

For more information, see Network Suite Variables.

For synchronization purposes, you can also use special network suite methods and events. For example, to ensure that the execution of a project resumes only when a particular network suite variable gets the expected value or simply changes its value, you can use the NetworkSuite.WaitForNetVarChange method in this project. Alternatively, you can specify the appropriate processing in the handler of the OnNetVarChange event, which occurs when a network suite variable gets changed.

Another way of synchronization is checking the state of a particular job, task, host or the entire network suite. Using the Job.State, Task.State, Host.State or NetworkSuite.State properties you can simply check the state of the desired object. A bit more sophisticated method is to suspend the test execution until the object gets the expected state: use the Job.WaitForState, Task.WaitForState or NetworkSuite.WaitForState methods to do this. You can also check the state of jobs, tasks and the entire network suite, using the OnNetJobStateChange, OnNetTaskStateChange and OnNetSuiteStateChange events. TestComplete lets you create script routines that handle these events. This allows you to perform specific actions when the events occur. For information on how to create event handlers for TestComplete events, see Handling Events.

By default, any project engaged in distributed testing can change the value of any NetworkSuite variable. Sometimes this behavior can lead to certain problems. For instance, when several projects try to change the same NetworkSuite variable simultaneously, or one right after the other but you cannot say for sure what value the variable will have in the end. In these situations, results would be more predictable, if you could guarantee the following: when a project changes a variable's value, other projects that are going to change the same variable have to wait until the first project finishes its modification. This strategy is possible if you use critical sections. Each critical section is a specifically marked section of code to which access is given exclusively to one project at a time. Critical sections are a good place to put not only code that modifies desired NetworkSuite variables but also code that writes to any critical resource available from scripts and keyword tests (for example, project and project suite variables, files, databases, and so on).

For more information, see Critical Sections.