I've just become involved in the effort to make our test suite available and we have an internal meeting later today to discuss the procedures around this. I would have thought that the first sensible step would be for us to split out our current tests into two packages - those that have dependencies on RW internal classes and those that don't. That way we can provide regular code drops of the generic tests (avoiding the need to provide diffs when we make changes) and we can gradually migrate tests from the RW suite to the generic suite.
Does that sound like a workable solution? Thanks, Andy. -----Original Message----- From: kelvin goodson [mailto:[EMAIL PROTECTED] Sent: 01 November 2006 10:05 To: [email protected] Subject: Re: SDO Java: Getting Involved -- Tests/Samples Andy, that's great thanks. This begs the question of how we proceed with code edits. Would you able to supply any updates you make as patches attached to a JIRA. I can then apply them to the code in svn. If you need any help with that I'm more than happy to help. (If you want interactive help I'm likely to be watching the IRC channel as "kgoodson" on the #Tuscany channel on irc.freenode.net.) It would be good to understand how you are currently working with this code in terms of source code control etc. and what your plans are as we move forward with this effort. Best Regards, Kelvin. On 01/11/06, Andy Grove (Contractor) <[EMAIL PROTECTED]> wrote: > > 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: [email protected] > 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: [email protected] > 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: [email protected] > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
