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

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dave,

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.

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.

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.

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.

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.

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??  ;-)

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....

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
e-mail:booz@us.ibm.com

---

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