Jacques and all,
Here is my
synopsis of the issues discussed in yesterday's call. I am
beginning modification
of the test framework specification based
upon these resolutions. Please let me know if I
have correctly captured
them.
[Jacques Durand] OK for all
previous.
- if-then-else: where usable
[MIKE] -
<If><Then><Else> can be inserted anywhere within a
<Thread>. The construct is:
<If
ifType="andIf/orIf">
...
...
...
<Then>
...
...
<ElseIf
ifType="andIf/orIf">
...
...
<Then>
...
</ElseIf>
<Else>
...
..
</Else>
</If>
[Jacques Durand] So what could we have as arg of
the "if"? woudl that be an XPath expression, like for Assertions? if we
allow for such an expression, along with boolean ops, do we really need the
"ifType" attribute?
- management
of the message store, semantics of putting and getting
messages.
[MIKE] - This was not thoroughly
disccuess on the conference call due to time limitation.s
Agreed
that "deletion" of
messages was likley to cause side-effects in a message store when
concurrent <Thread>s are accessing
the same messagestore and that an optional "masking"
of a message store ( perhaps at the <Thread> level ( i.e. having a new
"virtual" message store,
local to that<Thread> whose lifecycle is the duration of that <Thread>. Incoming messages would
go to that <Thread>'s local message store, but would also be
placed in the "global"
messagestore.
<GetMessage> operations within that
<Thread> would only have access to the local message
store. Comments? If this is
an agreeable approach, then I can update the message store
semantics
in the test framework
specification.
[Jacques Durand] For simplicity, I wouldn't deal with
thread-level "view" of the store...how about:
- let us completely
forget about the notion of thread when dealing with the message store: The
store is specific to the test case, and all test steps - regardless of
which thread they are in - will have same view of the store,
- Effect of a
GetMessage step : it may "mask" (mask="true") messages it selected through its
filter, and these messages will not be visible anymore to other test steps in
the test case (from whatever thread). It may also "unmask" (mask="false")
so what it selects is still accessible. Default is
"true".
- from there, it is up
to the test case writer to manage all side effects, e.g. via proper thread
synchronization (join), and proper GetMessage filters, and proper
masking.
- PutMessage has no effect on the
store.
- test case exit values:
"pass/fail/notapplicable"? Exit statements.
[MIKE] - Agreed during the conference
call that the "true" result of a
<TestAssertion> could optionally
contain an exitCondition attribute whose value
may be "pass", "fail" or "not
applicable".
- the PreCondition role in
GetMessage.
[MIKE] - We discussed this in the ongoing
mail thread, with ( I believe ) the agreement
that the test writer does not necessarily
have control of all testing preconditions
(e.g. a candidate MSH may send its
messagesa as "multipart/related" or "text/xml"...
so a <TestPrecondition> is
necessary so as not to fail a <TestCase> because an
optional
features was not
implemented
[Jacques Durand] agree with that. Although in many
cases where we (test case writer) have enough control on the test
material we produce, this precondition wouldn't be needed, even if it was used
in the "Test Requirement" script. In other words, just because there is a
precond in a Test Req does not mean we have to use one in the Test
Case.
[MIKE] - Other issues
include:
Global Threads -
<Thread>s defined at the <TestSuite> level.. Useful for such
things as
global "exit" operations, or often used
sets of <TestStep>s that vary only with the
<ConversationId> or
<Timestamp> values. I suggest adding a global <ThreadGroup>
at the
<TestSuite> level to permit
definition of such global <Thread>s. Comments?
[Jacques
Durand] why not, but it remains to be seen how reusable such a "thread"
could be...So far I see that most test cases have specific test
assertions, even if the sequence of test steps looks the
same.
Have we defined how "parmeterized" threads can be?
-----------------