Re: [sca-assembly] [ASSEMBLY 205] TEST_ASM_12001 has empty composite nam

Assembly-205 is *not* arguing the test case is invalid. Below is the issue text for reference:

"TEST_ASM_12001 in TestConfiguration provides an empty composite name (the test attempts to verify that all deployables in a composite are deployed if no composite is specified). Besides being a dubious test (it relies on the runtime bridge and runtime deployment API to do this), it demonstrates Testconfiguration is not intuitive as the composite to run comes from multiple sources in TestConfiguration."

Assembly-205 is raising two points:

1. The test harness API/SPI is inconsistent and can be simplified
2. The test case as it is implemented may not test what it is intended to

To start with the first, I found the runtime bridge API confusing, in part because configuration is not handled consistently and there is no API documentation. I outlined the inconsistencies and proposed a solution in an email dated 13 December 2009, which was not responded to. The email was cited in Assembly-205:

One of the main inconsistencies is the scattering of test configuration sources. Consider the following two methods on RuntimeBridge:

public interface RuntimeBridge {

public void setTestConfiguration(TestConfiguration testConfiguration);

boolean startContribution(String contributionLocation, String[] contributionNames) throws Exception;

and TestConfiguation:

public class TestConfiguration {

public String composite;

public String[] contributionNames;

// ....

}

Why are two sets of contribution names present in the API, those passed into setTestConfiguration via a TestConfiguration instance and those passed as a parameter to startContribution? What SCA assembly concept does the composite field on TestConfiguration map to? Is it a deployment composite? If it is not, where in the SCA specifications does it allow for composites that are not marked as deployable in the contribution manifest to be directly included in the domain? If the composite field is null, how should it be treated? Two ways to solve these issues is to make composite field represent a deployment composite or remove it entirely and rely on the deployable mechanism in the contribution manifest (i.e. a "An SCA runtime MAY deploy the composites in <deployable/> elements found in the META-INF/sca-contribution.xml and META-INF/sca-contribution generated.xml files"). However, the issue with the latter is that it is an optional behavior, which means the test case should be marked as such.

The second point is that given these inconsistencies, that test must rely on the implementation of RuntimeBridge to figure out the correct behavior such as interpreting a null composite name to include all deployables. This arguably means the test does not correctly verify the test case.

Jim

On Feb 23, 2010, at 7:09 AM, Mike Edwards wrote:

Folks,

Assembly issue 205 (http://www.osoa.org/jira/browse/ASSEMBLY-205 ) argues that
testcase ASM_12001 is invalid since the TestConfiguration contains a set of Contributions to use, but
does not supply the name of any Composite to run.

My view is that the testcase is valid and does not need to be changed. Hence we should close this issue with no action.

Here is the configuration in the test client:

config.testName = this.getClass().getSimpleName().substring(0, 9);
config.input = "request";
config.output[0] = config.testName + " " + config.input + " service1 operation1 invoked" ;
// null composite supplied - the name of the composite to run comes from the sca-contribution.xml
config.composite = null;
config.testServiceName = "TestClient";

config.contributionNames = new String[] { "ASM_12001", "General", "General" + _Lang };

The relevant things are:

a) the list of contribution names assigned to config.contributionNames
b) the value of config.composite, which is null

In the design of all the testcases, the configuration has one or more Contributions, which are intended to contain the artifacts to use, plus
the name of a Composite to run. It is expected that the Composite exists somewhere in the supplied Contributions.

In this testcase, one of the contributions - ASM_12001 - has an SCA contribution which has a contribution.xml file as follows:

<contribution
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
xmlns:test="http://docs.oasis-open.org/ns/opencsa/scatests/200903">

<deployable composite="test:TEST_ASM_12001"/>
<import namespace="http://docs.oasis-open.org/ns/opencsa/scatests/200903"/> 
<import namespace="http://test.sca.oasisopen.org/"/> 

</contribution>

Note the presence of the <deployable/> element, referencing a specific Composite.

The design of this test is intended to check that the SCA runtime will deploy the composite referenced by the <deployable/> element.
Either this test is correct as written, or the argument must be made that an SCA runtime does not have to do anything with the <deployable/> element.
If that is the case, then the whole testcase should be removed as the function is optional.

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

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

sca-assembly message