[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-iic] Use cases for concurrent test cases - Schema and instance examples
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. - 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
|