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
