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