A place for jotting notes on how the RogueWave sample tests fit in with the current Tuscany set up.

general points

Tuscany currently expects all test case class names to end with "TestCase"

In Tuscany, we don't use the INSTANCE singletons in tests wherever possible, since they can cause cross test interference especially when using maven, since maven builds an ubertest, and so there is more scope for one test changing the state of an instance prior to running another.

We should consider the use of suites of tests in our test architecture

We can use RogueWave's TestHelper as a prototype for abstracting away common operations -- I have made a first pass at this.

We must identify and separate implementation specific tests, such as testGetAttribute()'s method.

    // ensure we default to caching on
    assertEquals(((XMLDocumentImpl)doc).getOption("xpath-caching"), "true");
    assertEquals(3, docImpl.getXPathCacheSize());

We should have a policy such as no common code can contain an import of o.a.t.s or of c.r.r.s

Wherever the SDO API can not handle a particular requirement, an abstraction method is defined on a shared test helper interface and rigorous assertions are made in javadoc in the interface to specify what is required of the implementation.

How about once we have done an initial pass on abstractions of test utilities we require the implementor of a new utility method to implement a mockObject method before inserting the new code into svn. Maybe we could have an abstract base class for this, with mock object methods wherever there are gaps in one or more implementations. The base class using mocks should signal in the test log that mock objects are being used. We could even use assertions in the mock method to document what must be true of a true implmenetation of the utility method.

We need an abstraction or a common policy for locating test data. In tuscany we tend to do this by having resources available to the class loader. The RogueWave method currently causes all tests in the XMLDataObjectTest program to fail; it would work if I got the test data and oput it in the right place, but it's a bit fragile. BTW, I have this compiling cleanly, (with a few tests commented out).

DataObjectListTestCase

It would be good to discuss the intentions of the createTestObjectTypes method. It highlights some conventions we could adopt in type/property naming, to keep things clear, and I'm not sure what's there is what was intended.

I have annotated my local code ...

                /*
                 * create type system
                 * catalog2
                 *  - product2:DataObject[isMany:true]
                 * 
                 * product2
                 *  - nameTest:String
                 * 
                 * my guess is that the intention is
                 * catalog2
                 *  - product2:product2(isMany:true)
                 *    - nameTest:String
                 */

Frank looked at this on 26th October and put a note on Tuscany-829.

Out of 23 tests, 2 end in error and 3 in failure.

testAddObject ... {{{java.lang.IllegalArgumentException: Class 'AnyTypeDataObject' does not have a feature named 'product2'

}}}

this relates to Frank's comment ...

1. RogueWave seems to assume that TypeHelper.define() defines both a Type and corresponding global element for it. Tuscany only defines the Type and requires a global element be created separately. Although the spec doesn't spell this out exactly, I think that RW has it right because even though it doesn't say that TypeHelper.define() does this, it does say in the SDO to XSD mapping section, that an SDO Type generates both a complexType and a global element. I suggest that we open a JIRA to fix this in Tuscany. 

since loading the document

assumes that TypeHelper.define() on

would create a global element "catalog2"

I've opened http://issues.apache.org/jira/browse/TUSCANY-887 to deal with this.

The same issue gives rise to the errors to be found in methods

Tuscany issue -- adding null to a list

        XMLDocument doc=loadDocFromString("<catalog2><product2/><product2/></catalog2>");
        List listTest=createTestObj(doc);
        assertNotNull(listTest);
        
        try{
            listTest.add(null);
            fail("no exception were thrown");
        }

gives ...

junit.framework.AssertionFailedError: no exception were thrown
        at junit.framework.Assert.fail(Assert.java:47)
        at com.roguewave.rwsf.sdo.DataObjectListTestCase.testAddNull(DataObjectListTestCase.java:224)

It would seem from testSubList that Tuscany's FeatureMapUtil$FeatureEList doesnt behave well when viewed through a java SubList

        assertEquals(3,listTest.size());
        
        List listRes=listTest.subList(0,1);
        
        assertNotNull(listRes);
        assertEquals(2,listRes.size());


junit.framework.AssertionFailedError: expected:<2> but was:<1>

        at junit.framework.Assert.assertEquals(Assert.java:207)
        at com.roguewave.rwsf.sdo.DataObjectListTestCase.testSubList(DataObjectListTestCase.java:465)