Title: call tomorrow Wed 8th, 3pm PT
Mike:
No big deal
you missed the call - there will be other ones...
I think we
should phase the "abort" for a later release after this one.
This is
too recent a feature, and more thinking is needed on it, even if we seem to
agree on an interpretation.
The "return"
is OK however, as it is really a convenience faeture clearly understood with
limited implications.
Regarding
Section 7.1:
- I think we
should give it more exposure and move it up in Part I , e.g. as a new section
3.4,
just after
the section 3.3 "executing test cases". I am even in favor of moving it up
further than that:
It could fit
just before Section 3.2.4 (i.e. just after the general description of Test
Driver and Test Service,
and before
the lengthy description of Test Service actions (3.2.4),
so that
people have a feel of how all this works
together.
We just need
to extend a bit with succinct and informal introduction of some notions
used (GetMessage, PutMessage, TestAssertion) as we already
do
with Threads.
So this
second option would give something like:
Part
1:
3.1 Test
Driver
3.2 Test
Service (would contain 3.2.1, 3.2.2, 3.2.3)
3.3 Execution
of a Test Case in the Test Driver (formerly 7.1)
3.4 "The
Messaging Actions and Messaging Services" (formerly 3.2.4)
3.5 Interface
for Test Driver and Test Services (formerly 3.2.5)
3.6..
Part
2:
...
Whether we
put it as 3.3 above, or just at the very end pf Part 1, I think "7.1" is at its
place in Part 1, as it
illustates
the behavior of the test Driver. Part II is about the representation of Test
Suites, which is not really the
objective of
7.1. which is rather to give a flavor of how test case operates when executed,
what it can do (i.e. what a test driver
can
do).
Opinion?
And for the
editing of 7.1, again I'd forget about "abort" operator, and rather
discuss on the several points (most editorial)
I reported in "section7.1-JD1_MK_JD2_MK2-JD3.doc" sent
yesterday.
Cheers,
jacques
-----Original Message-----
From: Michael Kass
[mailto:]
Sent: Wednesday, September 08, 2004
12:36 PM
To: Jacques Durand; ebXML IIC - main list (E-mail)
(E-mail)
Subject: Re: [ebxml-iic] Section 7.1 of Test Framework
revision.. using Jacques workflow approach (option B)
Jacques and all,
I updated section 7.1 (attached)with
modifications reflecting Jacques suggested "abort" of <Thread>s based
upon failed TestAssertion results,
and "abort" of the parent <Thread> if a
subsequent <Join> cannot take place.
I believe that this approach would satisfy
the requirement of being able to exit on a failed <TestAssertion> if it
is deemed that
the <Thread> containing it is critical to
the continuation of Test Case script execution (determined by its presence in
a subsequent
<Join> operation. If that
<Join> operation cannot take place because of the aborted
<Thread>.. then the <Thread> containing the
<Join> is also aborted, and logic control
reverts to ITS parent <Thread> .. and on .. and on... until the main
<Thread> (i.e. the
<TestCase> itself) is reached.
If script execution cannot proceed at the
<TestCase> level (due to an unsatisfied <Join> condition), then
the <TestCase> exits with
a final result of "fail". So a failed
<TestAssertion> may or may not be significant in the overall testing
logic, depending upon whether
dependent <Join> conditions are
satisfied.
Regards,
Mike
