RE: [ebxml-iic] scripting of test cases: latest advances

Jacques and all,

Attached is a schema image, along with 3 use case documents (XML and HTML rending) reflecting the latest schema. A number of simplifications have been done with this iteration, including:

1) Elimination of Test Step container for PutMessage and GetMessage operations.

2) ConfigurationGroup now contains a

<StoreAttachments> Boolean element. Default Test Driver behavior will be to “not” store attachments (set to “false”).

<Transport> element (could contain FTP, HTTP or SMTP

<Envelope an implementation-dependent hint to be used by Test Driver..

<StepDuration> .. a timer ( measured in integer seconds) specifying maximum time a Test Driver should wait for <Filter> operation or a PutMessage operation to complete before exiting with an “undetermined” status for the Test Case

<ConfigurationItem> is replaced with <SetParameter> to create a parameter name/value pair list.. global in scope for the <TestSuite>.. but also redefineable at the <Thread> level

3) <TestServiceConfigurator> is an RPC call to Test Service, providing 4 parameter name/value pairs. This is an “optional” element, since some Test Services may not permit remote configuration.

4) <Thread>s now can do everything a <TestStep> can do. Also, <TestAssertion> is now moved outside the scope of the <GetMessage> operation, to the <Thread> level

5) <SetParameter> within a <Thread> defines (by default) a name/value pair with a default scope of “selfAndDescendents”… meaning its scope is global to the current <Thread> and any of its child or ancestor <Thread>s. You can “override” that default behavior by setting the “scope” attribute to “self”.. meaning the parameter is not passed to descendent <Thread>s.

6) <Initiator> is an RPC call to the Test Service, in which a <MessageDeclaration> is sent to the Test Service, to be parsed, interpreted and to generate a real message from the Test Service. Payloads to be attached by the Test Service MAY also be sent in the RPC message.

7) TestPreCondition is gone. TestAssertion now performs both roles of <TestPreCondition> and <TestAssertion>. <TestAssertion> verifies content of the “current” <FilterResult>. The current <FilterResult> is the result of a <Filter> query on the <MessageStore>

8) <SetXPathParameter> can set a parameter value based upon the result of an XPath query defined in the <Expression> element. This can be done for either the Message Envelope.. or an XML Message Payload. It’s scope is defined for the <Thread> in which it resides, and any ancestor <Thread>s by default.

9) <VerifyTimeDifference> is a new child of <TestAssertion> differences the time between two supplied parameters, using an operator of ( <, <= , = , >= )

10) Lastly… I’ve added a <WhenTrue> and <WhenFalse> child element (optional) to <TestAssertion> this is conditional branching based upon the Boolean result of the <TestAssertion>. <Split> means spawn “concurrent” <Threads>.. <Continue> means continue execution based upon the Boolean result… <Exit> means stop <TestCase> execution.. with a final result as specified by the <Exit> element.

TestAssertion logic rules

Default behavior (meaning.. now <WhenTrue> of <WhenFalse> child elements are present in <TestAssertion>:

Any operation (VerifyContent, ValidateContent, VerifyTimeDifference) that returns a boolean “true” means the Test Driver will automatically proceed to the next operation in the <Thread>

Any operation (VerifyContent, ValidateContent, VerifyTimeDifference) that returns a boolean “false” means the Test Driver will automatically cease execution of the Test Case, and return a final Test Case state of “fail”.

Rules for <VerifyTimeDifference> are:

The equation for evaluation is:

1^st <ParamName> - 2^nd <ParamName> <Operator> <Difference>

(A) – (B) < (C) or A) – (B) <= (C) or (A) – (B) = (C) or A) – (B) > (C) or (A) – (B) >= (C)

Rules for <WhenTrue> and <WhenFalse> are: when a <TestAssertion> operation returns a Boolean “true” or “false” result:

a) a) <Continue> – (the default behavior) may be explicitly set with the <Continue> element).. means Test Driver continues execution if preceding VerifyContent, ValidateContent, VerifyTimeDifference operation returns a Boolean “true” result.

b) b) <Split> - Test Driver will fork one or more concurrent <Thread>s if preceding VerifyContent, ValidateContent, VerifyTimeDifference operation returns a Boolean “true” result.

c) c) <ThreadRef> - Invoke a <Thread> (via reference) to be executed serially

d) d) <Thread> - Invoke an “inlined” <Thread> to be executed serially

e) e) <Exit> - An unconditional instruction to the Test Driver to cease execution of the Test Case and set the final Test Case result state to either: “pass”, “fail” or “undetermined” (“undetermined” result would be used if a <TestAssertion> is used as a replacement for <TestPreCondition> (which no longer exists)

ebxml-iic message