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


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [sca-assembly] Continuing Test Assertion and TestCase review - section6

<dab> inline responses </dab>

There is only one item left to discuss below.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093

Inactive hide details for Mike Edwards ---06/02/2009 06:37:25 AM---Dave, Many thanks again.Mike Edwards ---06/02/2009 06:37:25 AM---Dave, Many thanks again.


Mike Edwards <mike_edwards@uk.ibm.com>




06/02/2009 06:37 AM


Re: [sca-assembly] Continuing Test Assertion and TestCase review - section 6


Many thanks again.

Responses inline in red

Yours, Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com

From: David Booz <booz@us.ibm.com>
To: sca-assembly@lists.oasis-open.org
Date: 01/06/2009 13:21
Subject: [sca-assembly] Continuing Test Assertion and TestCase review - section 6

Continuing with Section 6; I'm looking at SCA_Assembly_Test_Assertions_16.odt, SCA_Assembly_TestCases_22.odt and the CD03 assembly spec.

25) TA-6001, 6002, 6003 seem to be testable. I note that ASM_5016_TestCase and TA-5016 are similar.

Yes, TA-6001, 6002 and 6003 are in principle testable.

However, you can't test them by doing anything directly with some SCA Runtime.

Instead you have to write all the test code yourself - it isn't the SCA runtime that is under test, it's the

interface documents themselves.

This is a VERY big task. If you want to check out the size of the task, you could do worse than look at

the code that does this checking inside the Tuscany runtime. It is not trivial.

So I decided that it was a place that it was not useful to go and marked them "untestable" - meaning

untestable with practicable resources in this case.

TA-5016 / ASM_5016_TestCase are not at all similar. This IS a test against an SCA Runtime with the

given facts being that there are 2 interfaces that are known a priori to be subset/superset (or not, for

a negative version of the testcase) - but here the relationship is BY DESIGN, not something that is

established by running the testcase.

<dab> I don't follow your apriori argument. I don't think it's true. The context for ASM60015-20 is interface compatibility (see lines 1789-1806) and can all be tested as a side effect of a test that is similar to ASM_5016_TestCase. For example, two components wired together with different operations on each interface such that there is no subset relationship between them, would certainly prove whether or not the runtime is performing the right interface comparisons (ASM60016). All you have to do is vary the differences between the two interfaces according to the cases described by ASM60015-20. This is precisely the same computational comparison that the runtime has to do in ASM_5016_TestCase. We will have this same problem in the Policy TC where we will be testing the effect of the runtime doing the right thing, but we cannot directly test the runtime. </dab>

26) nit Service1SuperSet.wsdl is missing line breaks in the schema section - I checked in the fix for this

Thanks - this is the result of the standard Java2WSDL tooling - why tool writers think that leaving

out line breaks is a good idea escapes me completely.

27) TA-6011 - the test case ASM_6007_TestCase references TestComposite21.composite but the composite reference in there does not use a superset interface. I also think you should expand the test to include multiple promotions (similar to ASM_6006_TestCase but as a positive test).

Thanks for spotting a bug. TestComposite21 should use Service1Superset as the interface on the reference - this was left out when moving from Java

interfaces to WSDL. Now fixed.

<dab> ok, DONE </dab>
The expanded test that you suggest with multiple promotions would in my opinion be a new, different testcase. We can think about that as part of the public review.

<dab> I added it to my list of "deferred to PR" work. DONE </dab>

28) TA-6012 - the test case ASM_6007_TestCase references TestComposite22, but according to ASM60013, I think the test should work (the runtime should use the Service1SuperSet interface for the composite reference). The TC document declares 6007 as a negative test.

First, I'm assuming that you're talking about ASM_6008_TestCase, not 6007.
<dab> yes </dab>

I think TestComposite22 is in error and should fail. It has a composite reference which promotes two different component references.

The composite reference has no <interface/> declared. Each of the component references has an <interface/> declared but they are

not the same. One is Service1 the other is Service1Superset.

ASM_TA_6012 has a predicate that states that all the interfaces declared on the component references must be the same interface

in the case that the composite reference does not declare an interface itself. This follows from the normative statement ASM60008

- you may think that ASM60008 is in error, but that will require an issue raised against the Assembly spec.

<dab> Very interesting. ASM60008 is incompatible with what ASM60013 says, which is that the composite reference would have the superSet interface. I raised an issue for this. DONE </dab>

29) TA-6014 and ASM_6032_TestCase are good - I'd like us to consider an additional test for ASM60010, where there are two components, each with a reference that is promoted to a single composite ref but where the component refs have MUX intents.

Care to write the additional testcase?? ;-)

<dab> I added it to my list of "deferred to PR" work. DONE </dab>

30) ASM_6017_TestCase actually has two possible outcomes. The runtime could have chosen TestComponent3 and therefore the expected response would be altered.
"ASM_6017 request service1 operation1 invoked third operation1 invoked"

Ah well, I even noted this in the TestCases document under this test. It is the only testcase with this feature and so I put off the evil work

required. Time to do that work....

<dab> Ok, I see that draft 23 of the testcase document has this change in it and the test harness has support for this too. DONE </dab>

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093

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]