RE: [ebxml-iic] Section 7.1 of Test Framework revision.. using Jacques workflow approach (option B)

[Jacques Durand <JDurand@us.fujitsu.com>]

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:michael.kass@nist.gov]
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