Re: [ebxml-iic] comments on use case #2, and on termination of test case - more comments

Title: comments on use case #2, and on termination of test case

Jacques,

     Following up on 
yesterday's discussion, I would propose a modification to the logic 
rules:

  
----- Original Message ----- 

  
From: 
  Jacques 
  Durand 

  
To: ebXML IIC - main list (E-mail) 
  (E-mail) 

  
Cc: '' ; '' 
  

  
Sent: Monday, August 23, 2004 4:01 
  PM

  
Subject: [ebxml-iic] comments on use case 
  #2, and on termination of test case

  

  
Mike: 

  
I think we need to tighten the semantics of a Test 
  Assertion failing without explicit exit statement: 
I am concerned that these implicit rules we have will be confusing 
  on complex test cases that have concurrent threads...

  
(see my comment in 1.1.4, attached) 
I would suggest we consider the following proposal: 
  
- no "fail" outcome is produced unless an explicit fail 
  exit statement is met during exec. 

  
[MIKE] - I suggest that "exit/fail" should remain the 
  "default" behavior for a <TestAssertion> with a "false" result, even in 
  a concurrent thread

  
(for example, what if  a concurrent Thread just 
  "listens" for Error messages if any are received?)  The 
default

  
behavior under the current logic scheme is for the Test 
  Driver to "exit/fail" if a <TestAssertion> finds an 
  Error message.  

  
Under the proposed new logic, the default result would be 
  that the the Error Listening Thread would "abort", and have no effect on 
  the outcome of the Test Case. 

  
I suggest that if we wish to <AbortThread>, that we 
  explicitly say so in the script, otherwise keep the logic for 
  <TestAssertion> simple and consistent throughout the Test Suite so as 
  to

  
minimize confusion: 

  
 

  
<Thread>

  
<TestAssertion>.... (some XPath 
assertion)

  
        
  <WhenFalse>

  
            
  <AbortThread>

  
        
  </WhenFalse>

  
</TestAssertion>

  
</Thread>

  
 

  

- no "pass" outcome unless an 
  explicit pass exit statement is met during exec. 
[MIKE] - Agreed. That is the current assumtion.  
  "exit/pass" MUST be explicitly set in the 
<TestAssertion>

  

- a failed assertion without explicit exit statement, 
  by default will "abort" the thread, but just the thread. 

[MIKE] - I suggest that <AbortThread> MUST be explicitly 
  set for a <TestAssertion> that returns a value of "false"
  

- a passed assertion without explicit exit statement, 
  by default will "continue" the thread. 

  
[MIKE] - Agreed. This is the current logic 
  assumption

  

- when threads are joined, an aborted thread will 
  automatically cause failure of an and-join (which aborts the container 
  thread). In case it is an or-join, the aborted thread will just be ignored by 
  the or-join (the or-join will fail if all joined threads abort). If a thread 
  that was split but never joined, aborts, then it just stops and is simply 
  ignored for the rest of the test case exec and outcome. 

  
[MIKE] - Agreed 

  
 

  
- if the Main thread of a test case aborts, the outcome is 
  "Undetermined" by default (this is the only case of implicit outcome, in 
  addition to other explicit "Undetermined" outcomes)

  
[MIKE] - There are a couple of issues here: 
  The only way a "Main" Thread could abort (based on 
  your suggested logic for concurrent Threads) is if it is concurrently run 
  (i.e. the Main Thread is  <Split>).  But if it is the Main 
  thread, why would you <Split> it?  Disregarding that,  if an 
  "abort"  means "terminate this Thread but continue execution" then the 
  Test Case would still execute successfully to termination, and should "pass" 
  (i.e. an "abort"  is saying that a concurrent Main thread's result 
  is "inconsequential").  

  
 

  
[MIKE] - Also, use of a "Main" Thread is a RECOMMENDED 
  PRACTICE.  There is no need to use a Main Thread in the Test scripting if 
  one is not necessary.  For example, with the ebMS Test Suite, a Main 
  Thread is not required for any of the 200+ Test Cases, since all 
  <PutMessage> ,<GetMessage> and <TestAssertion> operations 
  can be completed as child elements of the <TestCase> itself ( 
  which I believe can be considered a Main Thread).  This greatly 
  simplifies scripting as well.

  
 

  
Comments?

  
 

  
 

  
 

  
 

  
 

  
Some additional Comments starting p.5 of the attached doc 
  (mostly, use case #2). 

  
Also, I was searching for the section where we specify the 
  test step timeout (MaxDuration?) , in the draft spec, 
and did not find it (same for the "sleep" statement). 

  
Cheers, 

  
jacques 
<<section7.1-JD1_MK_JD2.doc>> 

  

  

  

To unsubscribe from this mailing list (and be removed from the roster 
  of the OASIS TC), go to 
  http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php.