Durand/Kass [ebxml-iic] 10/3/2002: Sample Test Cases - CPA Template

[Monica Martin <mmartin@certivo.net>]

See inline below.

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: Tuesday, October 01, 2002 3:40 PM
To: 'michael.kass@nist.gov'
Cc: 'ebxml-iic@lists.oasis-open.org'
Subject: [ebxml-iic] RE: sample 3 test cases


Mike:

-----Original Message-----
From: Michael Kass [mailto:michael.kass@nist.gov]
Sent: Tuesday, October 01, 2002 12:12 PM
To: Jacques Durand
Cc: 'ebxml-iic@lists.oasis-open.org'
Subject: RE: sample 3 test cases


Jacques,

   This "timeout period" is something that we need to integrate into our

Test Driver.  I was wondering if the CPA as defined would provide enough

information to the Test Driver ( assuming that it parses some "base" CPA
( or "mini-cpa" for configuration ) to determine what that "timeout
period" should be before 
checking the message queue ( or some persistent storage structure ).
   Will the "base CPA" contain all of the required information for the
Test Driver
to compute its own "timeout period" before checking for received
messages, or
will we have to assign some arbitrary value?  
[Jacques Durand]  I think it is better to have that as a
testcase-specific configuration parameter...
this is really a test driver control issue, only meaningful to the test
driver, and outside the scope of the CPA .
Maybe in the "operating party" column, we could specify some config
parameters for the
operator of this test step, in addition to the operator name (here
"TestDriver"), e.g. "Timeout=60" (in seconds).
The default value could be given at the beginning of the test suite, in
configuration parameters: e.g. "DefaultTimeout=120".
[Monica Martin] If the configuration parameters are identified and
mapped to the test step (but not a part of the test step), then they
could be reused.
See comments below on pre-loading suggested by Jacques.


 1)   Regarding your other comments for the 3 abstract tests.. I agree
that <Condition>
should be changed to <Precondition>.  It has a more direct meaning in a
testing sense.

2)   I will fix the typos on the "quotes"    

3)   Regarding either :
  (a) Using predifined CPAs for the "configurator" action, or  
  (b) using CPA "templates" and manipulating them like any other message
content... 

I would favor (b) simply for the expediency.  Or at least, I think that
we should leave that possibility open in our implementation
design.  That way, if the number of CPA templates becomes cumbersome, we
could treat the CPA
as just another payload, and manipulate that XML payload template
content the same way we would manipulate
an XML payload template for say  ... ebXML Registry testing.   

[Jacques Durand]  I would also try to avoid using Configurator
action.... . (Configurator action assumes the MSH is 
capable to dynamically handle new CPAs, which may complicate things
API-wise, may not be true of all MSH, etc.)
But we may still assume that all the CPAs we need are in reasonable
number and pre-installed / accessible... 
(that would be the simplest solution) Only in case there are too many of
these, (or too many combinations of 
CPA attributes to consider in our test cases) we will have to specify
how to generate
non-preinstalled CPAs from a template - and that could just be an XPath
assignment in a sub-operation, like for header manipulations. In that
case only, we would need the Configurator, to deploy on a the MSH local
to this Test Service. 
But I'd say we might not need do that if we don't need more than 20 or
30 CPAs, which is still a reasonable 
number of predefined CPAs... 
[Monica Martin] I think over time, both options may be used.  Starting
simply with option (b) may be the best first step.  If you look at the
response
from ECOM, the questions with OAG-NIST-ebXML Test Bed, etc., we have a
case to support the pre-installed CPAs (for simplicity and reuse). I
believe the CPPA envisioned that dynamic generation of agreements could
occur, but don't know if that viable from a business standpoint (let
alone technical) at this time.  Can we reference the Configurator option
as a function to consider in a later release?
 
 Comments?



Mike

    

At 11:57 AM 10/1/2002 -0700, Jacques Durand wrote:



Mike: 

review of your 3 test cases - mostly details. 
Note: should we set also some timeout parameter for each test case? or
test step? 
(e.g. when we count duplicates, and retries, we have to know when to
stop waiting...) 

regards, 

Jacques 

-----Original Message----- 
From: Michael Kass [ mailto:michael.kass@nist.gov
<mailto:michael.kass@nist.gov> ] 
Sent: Monday, September 30, 2002 10:10 AM 
To: Jacques Durand; 'ebxml-iic@lists.oasis-open.org' 
Subject: RE: [ebxml-iic] next call this Monday 



To all, 

    Here is XML representation of the 3 selected abstract tests. I will 
document/comment this for a clearer 
description.  This is for an initial look at structure and underlying 
object model. 

Mike