<< Multi-Application - template.t explained | Multi-Application - Code for concurrency test example >>
Multi-Application - GUI-based applications
<< Multi-Application - template.t explained | Multi-Application - Code for concurrency test example >>
client machines. The second argument is the name you supply in your main
window declaration in your test frame (frame.inc) file. For this example, the
frame.inc file specifies the following:
different test frame files.
function in your appstate declaration for this test. For this example, the
appstate declaration is the following:
GUI-based applications, you may find that you need to define your own base
state. It would be the application state that all your tests for this application
use. In this case, you would still pass this application state to SetUpMachine
so that your application would always be brought to this state at the start of
each testcase.
use an application state if you wanted to start from the main window each
time. If you have a number of tests that require you to bring the application to
the same state, it saves testcase code to record the application state once and
pass its name to SetUpMachine. You will probably place your application
state declarations in your test frame file.
specifies no application state, because SetMultiAppStates calls the
DefaultBaseState function in the absence of an appstate declaration.
SetMultiAppStates uses the information that SetUpMachine associated with
each connected machine to set potentially different application states or base
states for each machine.
the indented code block below it runs in parallel with all currently running
threads. There is no requirement that your testcase should drive all your test