OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Concurrent thread use cases using <If><Then><Else> syntax


Title: call this Monday
Mike:
 
Not much to complain about in your last sending :)
Here is attached some comments though, mostly checking some remaining gray areas.
 
few comments inline below too.
 
Jacques
 
 
-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Thursday, February 05, 2004 1:58 PM
To: 'ebXML IIC - main list (E-mail) (E-mail)'; jdurand@us.fujitsu.com
Subject: Re: Concurrent thread use cases using <If><Then><Else> syntax

Jacques and all,
 
 
  Here is my response to the ongoing thread regarding test case scripting.
It looks like we have nearly reached convergence.   I am attaching a revised schema
diagram reflecting changes, along with a ZIP containing the 3 use case instances,
along with schemas an XSL stylesheet.
  With the revised schema, ( including both <If><Then><Else> along with <Split> and <Join> elements ),
I am also including revised use case instance files reflecting those changes. 
 
  Some suggestions based upon these use cases:
 
1) If we define a "pass" <Thread>  and a "fail" <Thread>.. we may want to make the "global" ( i.e. defined
at the <TestSuite> level ) since they can then be used everywhere.  If we assume that the scope of a
<Thread> definition is only local to a <TestCase>... it just seems like a logical thing to do I think.
[Jacques Durand] still skeptical about the value of sharing "global "threads"... won't each thread vary based on the steps and test assertions content ? the conditions that lead to failure or success are different for each case.
 
2) I agree that there is no need to have a <Thread> evaluate to "true"... if we can instead just verify that
the last <TestAssertion> in the <Thread> evaluates to "true".. however.. there may be <TestStep>s  in a <Thread> where
there is only a <TestPreCondition>   or where there is only a <PutMessage> operation.  If a <PutMessage>
happens to be final "leaf node" in our <Thread> branch.. then there is no <TestAssertion> ( a <TestStep> with
a <PutMessage> simply  sends a message, and returns a "true" if it is successful. )  So I would suggest that
we simply state that as long as the final leaf node in a <Thread> branch, or a <TestStep> branch returns a
value of "true", then the logic flow may proceed after that branch. I am avoiding saying that the <Thread>  or <TestStep>
therefore evaluates to "true".. but in essence, that is what I am saying.
[Jacques Durand] see in my attached comments: we may need to consider an "undetermined" result for test cases. Even if a precond fails, that should not mean the test case fails: precisely the semantics of a precond is that if it fails, the test case is not meaningful ! In other cases, if no Assertion - e.g. just PutMessage, default could be "undetermined" too. The "pass" or "fail" semantics should ideally result from an explicit statement, and I think we moved toward this direction with the "exitCondition" attribute  in Assertions that explicitly says what should be the outcome (i.e. not implicitly based on the boolean outcome). Should we require this attribute at every exit point, even at the last step, or on a PutMessage? (default would be "undetermined" or "notApplicable
")
 
3) After revising the 3 use case instances, I agree with your earlier suggestion that a <Thread> be "synchronous" by default,
and that a <Split> be used to define it as "asynchronous".  It makes for much cleaner structure.. plus it enforces the
"synchronization" of <Thread>s through the <Join> operator.   I think that ( although a bit more verbose ).. it removes
ambiguities  and ultimately makes it more understandable. 
 
Regards,
Mike
 
 

scripting_issues_mk5_jd5.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]