RE: [ebxml-bp] RE: [ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)

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

Title: RE: [ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)

David:

 

That looks like quite a good start. Please keep us posted on the table as it evolves.

One remark: shouldn't we only report the "failure" cases,

because I guess a successful outcome would simply mean that "no failure" was reported

(e.g. assume

"isPositiveResponse" is "true", that does not necessarily make for a "success" of the transaction, in case

some other condition is false, right?)

 

>I also raised the issue that the guard condition should be associated

>with an interchange to make it clear when to apply what.  Again the

>model illustrates this in the main activity part of the diagram.

 

Well, that is what we call a "test requirement"... ebBP is certainly welcome to

define these, as we expect from any TC 

(an informal English description  - but precise enough - is sufficient for us in IIC

to derive test cases that verify this.)

 

Cheers,

 

jacques

 

 

 

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: Tuesday, May 25, 2004 7:51 PM
To: Jacques Durand; 'Monica J. Martin'; ebXML BP
Cc: Jacques Durand; Michael Kass
Subject: Re: [ebxml-bp] RE: [ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)

Jacques,

 

Dale and I talked about this last week - and creating a table of these for

the BPSS V2 specification.  We have specific names for these

boundary conditions.  The transport layer should signal the Outcome

to the named guard for the interchange condition test.

 

Here's my first take at this:

 

Condition	Outcome	Notes
isConfirmReceived	timeout	false
isRequestAcceptanceFailure	invalid	true
isPositiveResponse	protocol failure	false
isBusinessSuccess	business problem	false
isPositiveResponse	succeed	true
isBusinessSuccess	succeed	true
isConfirmReceived	succeed	true

 

 

Also - I've attached the JPG of the model I'm using to verify BPSS V2.

 

The Interchange Profiles have various transport characteristics, and

again these tally with things like "timeout" - setting the boundary

conditions when this happens (see far right side of the model).

 

I also raised the issue that the guard condition should be associated

with an interchange to make it clear when to apply what.  Again the

model illustrates this in the main activity part of the diagram.

 

Thanks, DW

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

From: Jacques Durand

To: 'Monica J. Martin' ; ebXML BP

Cc: Jacques Durand ; Michael Kass

Sent: Tuesday, May 25, 2004 8:53 PM

Subject: [ebxml-bp] RE: [ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)

To make it easier to follow-up on Monica request (my blurb she quoted is a bit
out of context), what we are looking for is:

- what are the possible failure cases for a BP engine supposed to run
a business transaction, that can be observed by the other party,
(we support so far: timeouts, not getting the right message in time, getting a message of the wrong kind, getting too many messages. Any specific instance

of these, or specific combination that we should care for?)

- a review of, or additions to the 3 use cases attached (keep in mind these cases
are intended to exercise various features of teh test framework, and do not necessarily represent typical BP transactions / collaborations.)

In these use cases, a test driver would simulate one party.

- any realistic case where there is looping involved from the testing party?
(e.g. iterating on: sending a message + receiving a message, until
the received message satisfies a condition.)

Thx,

Jacques

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@sun.com]
Sent: Tuesday, May 25, 2004 5:21 PM
To: ebXML BP
Cc: Jacques Durand; Michael Kass
Subject: [ebBP] [ebxml-iic] Scripting of Test Cases (Process Concepts)

ebBP team,
If anyone has any comments on the IIC work (applying relevant process
concepts to test framework), please let me know. Further details from
that team today.

Good progress. Thanks.

> Durand: We had a productive call yesterday, and also discussion after
> the call.
> I think we outlined a scripting solution that can handle every use
> cases properly, BPSS reqs,
> while keeping the scripting simple.
> Here is my summary of the consensus we reached, of course this needs
> to be validated
> after a detailed review and use case re-coding. Mike please correct if
> needed:
>
> Based on review of the three use cases and previous scripting:
>
> - When branching is required based on received message: either header
> data or payload data can be used. But only one GetMessage op execution
> should be needed (not one per condition outcome).
>
> - Branching (like needed in Use Case #3) will be done by invoking
> threads by name, within a split() op.
> - A thread, when invoked (whether within or outside a conditional
> statement), will inherit visibility of parameters from the invoking
> thread.
>
> - Because we did not want to spawn a thread from within a test step,
> and for other reasons, we came to the conclusion that it is better to
> extract the "Assertion" test outside of the GetMessage step.
>
> - The Assertion becomes a control flow operator: it may test
> FilterOutput material from several GetMessage inputs (these need be
> named), or may test value of variables (no message data).
>
> - The outcome of the assertion test will be stated explicitly (e.g.
> might be indicated via two attributes: "when_true", "when_false" that
> are just a representation for if..then...else, without the
> composability.) These statement effectively decouple the boolean
> result of an assertion, with the test case outcome.
>
> This was needed to handle "error-catching threads" that must fail the
> case when assertion is true.
> - The Assertion outcome (e.g. specified as value of above attributes)
> may be:
> . exit(...) with arg = fail/pass/undetermined. This terminates the
> test case.
> . continue (default). This let the test case continue its flow (next
> test step, thread join, etc.)
> . split(threadA [,...]). This spawn a thread concurrently to current
> thread.
> - Timeout may be simply handled by: (1) spawning a sleeping thread
> (sleep maxtime), (2) setting a flag variable when the last step is
> complete, (3) sleeping thread checks the status of the flag after
> sleeping, and makes decision (e.g. exit) if failure. This allows for
> any pattern of time checks (intertwined, etc.)
>
> - Looping ("while...do") can be handled by a thread invoking itself
> recursively, from an Assertion op.
>
>
> Jacques
>
>