scripting of test cases: latest advances

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: scripting of test cases: latest advances

We had a productive call yesterday, and also discussion after the call.
I think we outlined a scripting solution that can handle every use cases properly, BPSS reqs,
while keeping the scripting simple.
Here is my summary of the consensus we reached, of course this needs to be validated
after a detailed review and use case re-coding. Mike please correct if needed:

Based on review of the three use cases and previous scripting:

- When branching is required based on received message: either header data or payload data can be used. But only one GetMessage op execution should be needed (not one per condition outcome).

- Branching (like needed in Use Case #3) will be done by invoking threads by name, within a split() op.
- A thread, when invoked (whether within or outside a conditional statement), will inherit visibility of parameters from the invoking thread.

- Because we did not want to spawn a thread from within a test step, and for other reasons, we came to the conclusion that it is better to extract the "Assertion" test outside of the GetMessage step.

- The Assertion becomes a control flow operator: it may test FilterOutput material from several GetMessage inputs (these need be named), or may test value of variables (no message data).

- The outcome of the assertion test will be stated explicitly (e.g. might be indicated via two attributes: "when_true", "when_false" that are just a representation for if..then...else, without the composability.) These statement effectively decouple the boolean result of an assertion, with the test case outcome.

This was needed to handle "error-catching threads" that must fail the case when assertion is true.
- The Assertion outcome (e.g. specified as value of above attributes) may be:
. exit(...) with arg = fail/pass/undetermined. This terminates the test case.
. continue (default). This let the test case continue its flow (next test step, thread join, etc.)
. split(threadA [,...]). This spawn a thread concurrently to current thread.
- Timeout may be simply handled by: (1) spawning a sleeping thread (sleep maxtime), (2) setting a flag variable when the last step is complete, (3) sleeping thread checks the status of the flag after sleeping, and makes decision (e.g. exit) if failure. This allows for any pattern of time checks (intertwined, etc.)

- Looping ("while...do") can be handled by a thread invoking itself recursively, from an Assertion op.

Jacques