[jira] Commented: (TUSCANY-829) Investigate integration of RogueWave tests

["Kelvin Goodson (JIRA)" <tu...@ws.apache.org>]

    [ http://issues.apache.org/jira/browse/TUSCANY-829?page=comments#action_12445937 ] 
            
Kelvin Goodson commented on TUSCANY-829:
----------------------------------------

It would appear that the apache infrastructure issues that are happening at the moment means that the subversion commits I have been making in for this Jira are not being recorded against the JIRA.  The key commit is recorded here ... http://svn.apache.org/viewvc?view=rev&revision=469239  and I posted to the tuscany-dev mailing list describing my findings,  but again the mailing list archive has not picked up that posting.  I copy it here for reference,  but the discussion should continue on the mailing list.

=======
kelvin goodson 	
to tuscany-dev, luomo  30-Oct (17 hours ago)
I added the tests that were attached to TUSCANY-829 to my sandbox and made some changes,  see
http://svn.apache.org/viewvc?view=rev&revision=469239

The exercise has turned up issues in a number of areas; Tuscany specific,  interoperability,  ...

Looking at DataObjectListTest, one specific thing I'd like to understand is what was intended in the method createTestObjectTypes().  What it seemed to be doing is creating a very open model by setting the type of the product2 property to commonj.sdo.DataObject,  i.e. a mixed, sequenced, open type that can hold pretty much anything,  whereas what I think was intended was that this property should be of type newType2 (i.e. the type with name "product2").  Frank began looking at this with the view that what was intended was the former arrangement,  and the failures we were getting has highlit an issue with Tuscany that we don't create global properties to accompany type definitions created with TypeHelper.define(),  and we think we probably should,  so I have opened TUSCANY-887 to cover this.  This was a useful catch, but then I have taken the view that what was intended was that the type of the product2 property should have been product2, and so I have changed the type creation method,  and I have altered the test to fit this,  can you please take a look to see if I am right.  You can see the diff at ....
http://svn.apache.org/viewvc/incubator/tuscany/sandbox/kgoodson/roguewave-tests/src/test/java/com/roguewave/rwsf/sdo/DataObjectListTest.java?r1=469239&r2=469238&pathrev=469239

We have one remaining test failure in this test case which is the testSubList() test,  which I think may have revealed another Tuscany issue,  but I haven't dug into that yet.

I have altered the TestHelper to give implementations that I think will work when used by the XMLDataObjectTest but I haven't got close to running that one yet.   All the XMLDocumentTestCase tests currently fail because of the setUp method,  which requires access to the test data,  so if you could attach that data to TUSCANY-829 that would be great, thanks.

I've commented out some test cases that I didn't immediately know what to do with,  and added TODO flags to remind me to deal with those. 
In some places the assertions are for RogueWave specific implementation details such as

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


As to the more general points that can be gleaned from this exercise, this is what I have so far ....

My guess is that with the improvements in the 2.1 spec we can begin to move much of the function that is found in TestHelper back out to the tests themselves,  or at least code them as support methods in terms of the SDO 2.1 API.  I have some half baked ideas about how in general to abstract away any required implementation specific behaviour,  but not sufficiently well formed to be aired just yet.

We have recently tried to remove as many references to the INSTANCE fields in our Tuscany tests as possible,  because they can cause cross test interference.  Maven builds an uber-test from all the * TestCase.java files,  and runs that test as a single process,  so alterations to the state of say TypeHelper.INSTANCE in one test class can influence the execution of tests in another.  So now we tend to create local instances of the Helpers.  The SDO spec group has a proposal for deprecating the INSTANCE fields,  which was intended to be aimed at SDO 3,  but there's a chance that it  might come into SDO 2.1,  so we may be helped here with a new way of accessing helpers.

An easy rule to create is that no test case in the shared set of tests can directly import a class from an org.apache.tuscany.* package, nor from a com.roguewave.*  package.  If the test requires some implementation specific behaviour then that code must be housed in something like a TestHelperImpl class.

I've been making notes on the wiki at http://wiki.apache.org/ws/Tuscany/TuscanyJava/Tests/RogueWave/Samples,  but these are the main points distilled from that raw dump.  I'll keep looking at the remaining issues and post more here soon.

Regards, Kelvin. 
=======

> Investigate integration of RogueWave tests
> ------------------------------------------
>
>                 Key: TUSCANY-829
>                 URL: http://issues.apache.org/jira/browse/TUSCANY-829
>             Project: Tuscany
>          Issue Type: Test
>          Components: Java SDO Implementation
>    Affects Versions: Java-Mx
>            Reporter: Kelvin Goodson
>         Attachments: sdo.zip
>
>
> Investigation of bringing RogueWave tests into the Tuscany environment.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org