Mike:
-----Original Message-----
From: Michael Kass
[mailto:]
Sent: Tuesday, October 01, 2002 12:12
PM
To: Jacques Durand
Cc:
''
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:]
Sent: Monday, September 30, 2002 10:10 AM
To: Jacques Durand; ''
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
