[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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".
- 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...
- 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]
- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC