sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Comments on JMS test cases BJM_40xx and BJM_50xx
- From: Simon Holdsworth <simon_holdsworth@uk.ibm.com>
- To: sca-bindings@lists.oasis-open.org
- Date: Tue, 19 Oct 2010 12:17:20 +0100
Review comments for JMS testcase artefacts
for BJM_40xx and BJM_50xx
BJM_40001_TestCase: OK
BJM_40002_TestCase: The default operationSelector
has four cases, so I think we need four tests:
BJM_40002_1_TestCase:
one operation in the interface - positive test - that operation is invoked
BJM_40002_2_TestCase:
>1 operation; JMS user property "scaOperationName" set to
"nonExistentOperation" - negative test that this operation is
not valid (?) Or else a positive test with multiple operations, but
will that then fail on the wireFormat? The problem with the negative
test is that that then relies on the runtime also implementing 40011 correctly.
BJM_40002_3_TestCase:
>1 operation, no scaOperationName; XML message with root element - positive
test - this is currently tested
BJM_40002_4_TestCase:
>1 operation, no scaOperationName, no XML message, - negative test indicating
that "onMessage" is not a valid operation name (?)
BJM_40003_TestCase: I was expecting
the composite in this test to have a reference, as the setting of the scaOperationName
in the normative statement is "when using the default wire format
to send request messages", however the composite only has a JMS bound
service, and the test appears to be testing a response message not a request
message.
BJM_40004_TestCase: Only includes
a <service>, does not test default wireFormat on a <reference>
BJM_40004_2_TestCase: Only includes
a <service>, does not test default wireFormat on a <reference>
BJM_40005B_TestCase: Tests receiving
a request at a <service>, does not test receiving a reply at a <reference>
BJM_40005T_TestCase: Tests receiving
a request at a <service>, does not test receiving a reply at a <reference>
BJM_40006_TestCase: OK
BJM_40008_TestCase: This should be the
same as BJM40002 with the 4 variants, the only difference is that the composite
has operationSelector.jmsDefault specified in the composite for this case.
BJM_40009_TestCase: Same comments as
for BJM_40004_* TestCase, same tests but with wireFormat.jmsDefault specified
in the composite.
BJM_40010_TestCase: Does not result
in the correct operation being invoked. The selectedOperation value
is the value returned from the operationSelector; the corresponding name
value identifies the operation that should be invoked. In the composite,
the name value is operation1, so operation1 should be invoked, not operation2.
Also the test would be much clearer using a selectedOperation value
that is not the name of an operation in the interface. I have changed
the test to have selectedOperation="XYZ" set via the scaOperationName,
but the test fails against Tuscany now.
BJM_40011_TestCase: Looks OK but fails
as the expected output does not match the actual output (might be I have
the wrong version of Tuscany).
BJM_50001_TestCase: OK
BJM_50002_TestCase: As per earlier comments,
this needs to test for a failure when the bindingType for JMS in the definitions
file does not include the JMS intent in @alwaysProvides if that is possible.
Simon Holdsworth
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]