Jacques,
I've modified
the Test Framework scripting schema to reflect your suggestions for
a
"minimal thread" approach.
(in your orignal email below ). 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]
Done. 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.
[Jacques
Durand] I believe split has different
semantics
- 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. Provided a "type" attribute to <Thread>
element ( asynchronous, or synchronous )
- 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