Jacques,

 

     I’ve modified the Test Framework scripting schema to reflect your suggestions for a

“minimal thread” approach.   I’ve attached a schema graphic, along with the 3 use cases as

an XSL transformation to HTML ( for easier viewing ).  In addition, I am attaching a ZIP file containing

all of the XML instances and modified schemas.  Here are my comments for each of the suggestions

you provided:

 

- A Test Case could be seen as a related set of Test Threads. [Mike] – Done.   Plus I added the functionality that a <TestCase> can additionally  be a set of <Thread>s, and/or <ThreadRefs>  ( for reusability of <Thread>s via name attribute)

 

 

-  A Test Thread is identified by a "thread name" and is a sequence of test steps.  [MIKE] Added <Thread> as a tag, with name as an attribute.    I expanded a <Thread> to be either a sequence of <TestSteps> and/or <TestStepRefs> ( for reuseability ) and/or <If> statements

 

- The simplest test case is just one test thread. [MIKE] – Agreed

 

- An if-then-else is forking to either a single step, or to a thread name.  [MIKE] –Why not make if-then-else a AND/OR Split?  Then we could do more creative types of evaluations .. like <If> (a AndSplit  b ) <THEN> (c), <ElseIf> (f OrSplit g) then (h) else  (i)  (I did this with the schema, by providing  the <If> element with a “splitType” attribute. Then all child <Threads> or <TestSteps> are an <And> or <Or> operation.

 

-  At any point in a test thread, a test step could be a thread invocation. [MIKE]-  I suggest keeping a <TestStep> as the lowest common denominator ( only able to do a PutMessage or GetMessage operation ).  This provides a clear delineatino between a <TestStep> ( an atomic operation ) and a <Thread> (a series of one or more <TestSteps> )

This is reflected in the schema

 

-  A thread invocation is of one of two forms: sync(threadname), async(threadname). [MIKE] - Done

 

-  An asynchronous thread invocation will run in parallel to the caller (a kind of "split").[MIKE] – Agreed

 

-  A synchronous thread invocation will block the caller until is complete (e.g., if-then-else,

or a kind of subroutine) [MIKE] – Agreed

 

- with this model, an Exception handling (e.g. handling an error message)

could be defined as a thread (i.e. possibly several steps). [MIKE] – Agreed

 

One issue that still remains, and looms large, now that we’ve adopted asynchronous functionality, and nesting of <TestSteps>  is “scoping” and “synchronizing”  parameter/variable references between <TestSteps>.  This is a tricky subject, and we need to define how this will work.

 

Comments welcome,

 

Mike