Hi, I'm looking at doing some work in the CTS. I was looking back at Robbie's attached description about how to keep the tests "harness agnostic". I'm assuming that this is still a goal of the CTS although I may have missed something in my catching up. In my quest to make the CTS better I note that a number of the test case classes still extend the junit TestCase class. This is true for all test classes that have a setUp() method. One that doesn't inherit from TestCase is XSDSerializationTest, and adding a setUp method to this class doesn't cause junit to invoke it in my eclipse environment. I'm trying to work out whether I should I expect a 4.1environment to discover and execute the setUp method when junit is used in this way. I seem to have Eclipse junit plugins for 3.8.1 and 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in the way of configuration, so I can't be sure I'm using 4.1 behaviour.
I really would like to be XSDSerializationTests to execute setUp so that we can have a fresh HelperContext per test, and I guess the easy way out is to make the test class inherit from TestCase like the others, but I'd prefer not to introduce the explicit dependency on Junit if I can avoid it. Regards Kelvin. On 07/12/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
This sounds quite good. I have written some test cases with Brian Murray which I would be happy to contribute to tuscany. Identifying duplication and differences in similar tests would probably be an intersting excercise right off the bat. One decision that we spent a little time mulling over was the framework to use for our test suite. Originally we used the much loved junit harness which worked well. Different runtimes ( command line, J2EE Application Server, a Service Container ) have different classloader hierarchies etc. Without many modifications to the junit code it was difficult and quite ugly testing SDO within the context of a variety of runtimes which the SDO APIs will be used. We took the approach of writing general test libraries which can then simply be called from a variety of test frameworks such as junit or a simple J2EE or SCA Application test harness. I like this approach for keeping the actual test code very simple, allowing for integration a variety of test frameworks, and providing ability to test directly within the different runtimes people care about. Any thoughts on this ? Robbie On 12/1/06, kelvin goodson <[EMAIL PROTECTED] > wrote: > > Andy, > please attach them to the JIRA for this work and one of us can pick > them > up, thanks. > Best Regards, Kelvin. > > On 01/12/06, Andy Grove (Contractor) <[EMAIL PROTECTED]> wrote: > > > > > > Hi Dan, > > > > I was previously working with Kelvin Goodson to donate some junit > tests > > on behalf of Rogue Wave Software. > > > > These tests are written purely to the SDO API and I have validated > that > > the tests do run against Tuscany as well as Rogue Wave's > implementation. > > > > > > Should I send the tests to Kelvin? > > > > Thanks, > > > > Andy. > > > > -----Original Message----- > > From: Dan Murphy [mailto:[EMAIL PROTECTED] ] > > Sent: 30 November 2006 17:44 > > To: Tuscany Developers; Tuscany Users > > Subject: Proposal for a (Java) community test suite for SDO > > > > I would like to propose starting a community test suite for service > data > > objects (SDO CTS) implementations written in Java. Based on feedback > > from an > > earlier post this seems to be the first logical step in getting > > interoperable SDO implementations in all languages. I can see this > > leading > > to an interoperability test suite to check serialisation between > > implementations also works (across languages and implementations). > > > > Proposal for Community Test Suite (CTS) for SDO > > Develop a test suite to validate an SDO implementation behaves as > > expected, > > according to the community's understanding of the SDO specification. > > Should > > the specification appear ambiguous or unclear then the community will > > decide > > what to do; it may decide to test the area with an agreed expected > > behaviour, or decide not to test this area. Ambiguities will be fed > back > > to > > the specification group for clarification. Although we will run this > > against > > Tuscany, the test suite will only test things that we think any > > implementation should support. > > > > The SDO CTS will enable developers to choose or switch SDO > > implementations > > without the concern of having to re-code a significant proportion of > > their > > application due to differences between implementations. This community > > test > > suite will first focus on areas identified important to developers of > > > SDO > > applications. SDO users feedback and involvement will be crucial to > the > > success of this effort. Over time this may grow to include a large > > proportion of the SDO specification, however the suite should grow > > according > > to the community's desire, rather than attempting to be a validation > or > > compliancy suite. > > > > To encourage everyone with an interest in SDO to contribute and use > the > > suite, I propose we : > > > > 1. Create a separate module in SVN to separate this from Tuscany > > components and testcases. > > 2. Make use of a java package namespace that is not attributable to > > either Tuscany or any other SDO implementation: test.sdo > > 3. Refactor some of the existing Tuscany SDO Java test cases to > > remove > > any Tuscany specific coding and re-package these to the test.sdo > > namespace. > > 4. Accept tests from anyone who wishes to contribute them under > > normal > > Apache contribution conditions. > > > > > > SDO users involvement will be crucial to this effort, developers of > SDO > > implementations will benefit by contributing to and consuming a > > community > > test suite, rather than working on their own. > > > > Who's up for working on this with me ? > > > > If you are interested in joining this effort; have any concerns, > > comments or > > suggestions please append them... > > > > Thanks in advance to all those who volunteer :) > > Dan > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ Check out Charlie's al crapo blog at http://robbieminshall.blogspot.com * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
