[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Concurrent thread use cases using <If><Then><Else> syntax
|
Jacques and all,
Here is my response to the ongoing thread
regarding test case scripting.
It looks like we have nearly reached
convergence. I am attaching a revised schema
diagram reflecting changes, along with a ZIP
containing the 3 use case instances,
along with schemas an XSL stylesheet.
With the revised schema, ( including both
<If><Then><Else> along with <Split> and
<Join> elements ),
I am also including revised use case instance files
reflecting those changes.
Some suggestions based upon these use
cases:
1) If we define a "pass" <Thread> and a
"fail" <Thread>.. we may want to make the "global" ( i.e.
defined
at the <TestSuite> level ) since they can
then be used everywhere. If we assume that the scope of a
<Thread> definition is only local to a
<TestCase>... it just seems like a logical thing to do I
think.
2) I agree that there is no need to have a
<Thread> evaluate to "true"... if we can instead just verify
that
the last <TestAssertion> in the
<Thread> evaluates to "true".. however.. there may be
<TestStep>s in a <Thread> where
there is only a
<TestPreCondition> or where there is only a <PutMessage>
operation. If a <PutMessage>
happens to be final "leaf node" in our
<Thread> branch.. then there is no <TestAssertion> ( a
<TestStep> with
a <PutMessage> simply sends a message, and returns a "true" if it is successful.
) So I would suggest that
we simply state that as long as the final leaf node
in a <Thread> branch, or a <TestStep> branch returns a
value of "true", then the logic flow may proceed
after that branch. I am avoiding saying that the <Thread> or
<TestStep>
therefore evaluates
to "true".. but in essence, that is what I am saying.
3) After revising the 3 use case instances, I agree
with your earlier suggestion that a <Thread> be "synchronous" by
default,
and that a <Split> be used to define it as
"asynchronous". It makes for much cleaner structure.. plus it enforces
the
"synchronization" of <Thread>s through the
<Join> operator. I think that (
although a bit more verbose ).. it removes
ambiguities and ultimately makes it more understandable.
Regards,
Mike
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
