Hi Kelvin, I agree with your edits to the createTestObjectTypes() test in DataObjectListTest. This was clearly wrong. This has highlighted a general issue on some of our tests which we are now rectifying.
We are also investigating issues around INSTANCE variables and I agree that we should at least avoid using them in the test cases so that we can isolate the tests. I'll progress this here and get the tests amended. I like the idea of having one vendor-specific TestHelperImpl abstracted by an interface. I'll start the process of amending out tests to use that. Thanks, Andy Grove. -----Original Message----- From: Bryan Luoma [mailto:[EMAIL PROTECTED] Sent: 31 October 2006 19:58 To: tuscany-dev@ws.apache.org Subject: RE: SDO Java: Getting Involved -- Tests/Samples Thanks Kelvin, I attached the XML instance documents (testdata.zip) referenced from the junit test XMLDataObjectTest.java https://issues.apache.org/jira/browse/TUSCANY-829 The archive consists of the following documents: - catalog-10.xml - w3_sample.wsdl - lists.xml - simple.xml We are looking into the other questions/concerns and will be addressed shortly. Thanks, Bryan ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kelvin goodson Sent: Monday, October 30, 2006 2:22 PM To: tuscany-dev@ws.apache.org Cc: Bryan Luoma Subject: Re: SDO Java: Getting Involved -- Tests/Samples 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/roguewav e-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. On 18/10/06, Bryan Luoma <[EMAIL PROTECTED] > wrote: Hello, I am a member of the QA team at Rogue Wave Software. I work closely with the HydraSDO Development Team on the HydraSDO for XML product (C++ and Java). I recently attached a couple of sample Java tests that we currently have in our junit test-suite which exercise HydraSDO for XML. The zip archive (sdo.zip) has been attached to the following JIRA: http://issues.apache.org/jira/browse/TUSCANY-829 The archive consists of two junit tests (XMLDataObjectTest.java and DataObjectList.java) and a helper class (TestHelper.java). XMLDataObjectTest.java has 120 test-cases that test the DataObject interface. This test uses several underlying RW implementation specific classes to perform some of the work. This is not a generic SDO API test that is ready to integrate into Tuscany. DataObjectListTest.java has 23 test-cases that test "list" functionality of DataObject. This test does not use RW implementation specific classes and should be easier to integrate into Tuscany as is. TestHelper.java is used by XMLDataObjectTest.java to help create DataGraphs and load input files. The TestHelper also uses RW implementation specific classes. We are excited and willing to contribute SDO unit-tests to the Tuscany project. The purpose of this initial "drop" is to help identify what steps need to be taken in order to simplify/maximize our contributions and to benefit from additional SDO API tests authored by the Tuscany project community. Sometime in the near future, RW will attempt to separate the RW implementation specific tests from the generic SDO API tests as much as possible. There has also been discussion of implementing an abstraction layer that would allow Tuscany and RW to exchange tests to exercise the respective products. We also have C++ unit tests (cxxTest Framework) that we use to exercise HydraSDO. Sounds like this would be a separate JIRA all together? Thanks, Bryan Luoma -----Original Message----- From: kelvin goodson [mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ] Sent: Thursday, October 12, 2006 1:46 AM To: tuscany-dev@ws.apache.org Subject: Re: SDO Java: Getting Involved -- Tests/Samples Tom, Welcome to Tuscany! that's great! Thanks for offering to get involved. How should we proceed? I'd be most happy to assist you to integrate what you have to offer. We currently have a small collection of tests using the junit framework (see https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo/impl/src/tes t/java/org/apache/tuscany/sdo/) but there's significant scope for enhancement. BTW I'm going to make my response Java centric as Andrew has offered to help look at the C++ side of things. How about this for a proposal for how to proceed? I have opened a JIRA (this is our issue or bug tracking system if you are not familiar with these things --- please tell me if you are already an expert). The JIRA can be seen at http://issues.apache.org/jira/browse/TUSCANY-829 , and you can upload attachments to the JIRA, so we could perhaps use that to first attach a typical RogueWave test or two. I guess it's likely that there will be some modifications that need to be made with regards to setting up the test within our environment, but that way we could play and discuss how we might proceed with more tests. How does that sound? Best Regards, Kelvin. On 11/10/06, Andrew Borley < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: > > Hi Tom, > > Coming from the C++ side of Tuscany, I know we'd certainly be > interested in those C++ SDO tests - please get involved! > > Cheers > Andrew > > On 10/11/06, T Gould < [EMAIL PROTECTED]> wrote: > > Kelvin - > > > > We at Rogue Wave have been developing an SDO product, HydraSDO, and have > a > > seires of tests that might be easiliy modified so as to exercise your > Java > > SDO product. We would be very interested in providing our tests as well > as > > helping create a test environment (unless this has already been done) to > > futher test the SDO product. Additionally, we also have C++ tests. > > > > > > tom gould > > ------------------------------- > > > > As the Java M2 release is imminent it occured to me that it would be > really > > useful if there are users out there who are putting our code through its > > paces that you may be developing samples/tests which could usefully be > > contributed back to the Tuscany project and make it more robust. If you > are > > in such a position it would be really great to hear from you. > > > > Regards, Kelvin. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
