Re: [ebxml-iic] Latest Test Framework spec and errata changes -01/12/04

["Monica J. Martin" <Monica.Martin@Sun.COM>]

See inline.

> Kass: Jacques and all,
>  
>   Here are the latest spec and errata changes, based upon email 
> comments and "scripting syntax" thread.
> I modified the scripting syntax again ( this schema is different from 
> the one I emailed to the list on Friday).
> It is  based upon Jacques suggestion for threaded/asynchronous test steps.
>  
>   Sorry it took so long to get this out. I had the flu last week and 
> could not get caught up until today.
>  
> I believe that the XML syntax illustrated in the attached 
> *TestStep.jpg* file would provide all of the suggested features
> (Monica's either/or/concurrency/parallel and Jacques threads and 
> exception handling) with a minimum of (2) new  XML tags.
>  
> A summary of features is:
>  
> A <TestStep> can contain either a "PutMessage" operation, "GetMessage" 
> operation  or a group of one or more <TestStep> children..
> A <TestStep>, based upon success (boolean "true") or failure (boolean 
> "false"), can branch to an optional <Continue> or <Exception> tag  
> respectively
> The <Continue> and <Exception> tags are optional, and only necessary 
> if one wants to provide a branching option for a <TestCase>
>  

mm1: I just sent a hybrid concurrency scenario to the list that 'may' 
affect this. In addition, there may be an exception that is not 
substantive (in BPSS context) and parties may decide to continue. For 
example, it was initially determined when Business Collaboration 
Protocol (BCP) was discussed that a warning could occur when a specific 
signal was not received from a Requester to the Responder. A warning is 
issued and the process continues. Perhaps this involve a profile that is 
defined outside of the specification.

> A <Continue> and <Exception> branch leads to another <TestStep>  ( 
> this is your if/then/else case )

mm1: Perhaps this could handle the scenario above?

>  
> A <TestStep> can be asynchronous ( parallel ) or synchronous ( serial 
> ).  By default, it is synchronous unless the test writer sets the 
> asynchronous attribute to "true".
>  

mm1: Does asynchronous = parallel? Hmm....

> A <TestStep> can contain a group of <TestStep> children, connected by 
> "and" or "or", based on the value of the "connectivePredicate" 
> attribute of the <TestStep>
>  

mm1: May wish to look at the fork-join semantics in BPSS just to think 
about this a bit more. We had a learning session today, and it is fresh 
in the ebBP team's mind if you want to throw some questions.

> <Exception> and <Continuation> branching is based on the boolean 
> result of the <TestSteps> grouped by the  "and" or "or" predicate for 
> that <TestStep>
>  
> <TestSteps> can be nested to any depth, with boolean evaluation 
> beginning at the lowest level in the nesting and logically proceeding 
> up to the top level.

mm1: Here, given the case I asked about (and the concurrency case), does 
any depth give us the capability to understand what happens and isolate 
test errors? Thinking from a business process perspective and where 
dependencies apply - particularly in the case of asynchronous.

>   <TestSteps> are executed serially or in parallel, each based upon 
> its asynchronous attribute value of "true/false".
> Boolean <TestStep> forks are evaluated after completion of all 
> asynchronous <TestSteps> for that fork.

mm1: See comments above related to fork-join semantics.

> Groups of <TestSteps> are executed in a single asynchronous thread if 
> they are the children of an asynchronous <TestStep>.
>  
> You can have synchronous and asynchronous child <TestSteps> within an 
> asynchronous parent <TestStep> thread.
>  
> This schema only adds 2 new ( and optional ) tags to the current 
> schema <Exception> and <Continue>  ( plus an "asynchronous" and 
> "connectivePrediate" attribute to <TestStep> )
>  
> This would add a lot of power and flexibility to the current scripting. 

mm1: Is there a need to 'include' a reusable step from another schema 
file, and if so, how do we identify the master flow and what happens 
when dependencies apply?

>  I still need to test this model, and define BPSS use cases to 
> generate some POC test cases.
>  
>  and I welcome any comments. 
>  

mm1: 8-)