[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-iic] comments on use case #2, and on termination of test case
Jacques,
Below are some of my thoughts
regarding "abort". I think that it is a useful and necessary
function for concurrent Threads
that will later be "orJoined".
I think however, that <Abort> should be
explicitly set by the Test writer, since, in 99% of <TestAssertion>
operations in a typical Test Suite,
a boolean result of "false" for a
<TestAssertion> will signal a defaul exit condition for the Test
Case, with a final result of "fail". This is the case for
ebMS testing, and will likely be the case for
Registry testing as well. BPSS testing will of course have more complex,
concurrent Thread opterations
that would benefit this
functionality. However, making <Abort> the default logical branch on
a failed <TestAssertion> does not represent the typical use
case
in our test scripting.
Also, requiring the test writer to "micro
manage" every <TestAssertion> in the test suite, and explicitly set a
<WhenFalse><Exit>fail</Exit></WhenFalse>
and
<WhenTrue><Continue/></WhenTrue>
is (in my opinion) against the intuitive meaning of
a <TestAsssertion> operation, where "true" = "pass" and "false" =
"fail". Such
default behavior could be "overriden" in the
case of a (rare) "abort" situation. Forcing explicit declarations of
branching will require unnecessary
and labor-intensive micro-scripting for each Test
Case, where more intuitive default behavior rules for <TestAssertion> could handle the majority
of test cases.
I would like to propose keeping
the existing implied <TestAssertion> logic, but adding an explicit
<Abort> option for <TestAssertion> that would let the test
writer abort a
(concurrent) Thread if a particular <TestAssertion> fails.
Comments?
Mike
----- Original Message -----
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]