OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]