[ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

ebBP team,
If anyone has any comments on the IIC work (applying relevant process 
concepts to test framework), please let me know. Further details from 
that team today.

Good progress. Thanks.

> Durand: 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
>
>