On 11/30/06, Dan Murphy <[EMAIL PROTECTED]> wrote:
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 Hi Dan
"a community test suite for service data objects (SDO CTS) implementations written in Java". I can see why you need to a test suite the test Java implementations but do you believe that some of this work will be useful to other language implementations also. We've talked before about the interop schemas up on SVN in the interop directory. If, for example, in your new effort the community decided that it would be a nice idea to test that SDO load and saves XML files based on schema that reflect the mappings defined in the specs (something I would imagine that you would be interested in) then it would be good if you can take what we have and enhance or replace them. This would then be useful in a context wider than Java because we use these tests in C++ and PHP SDO also. If you were able to make improvements here that would be work we wouldn't have to duplicate. Are there any other SDO tests that you think we could collaborate on cross langauge? For example, clearly API tests would be difficult :-) but how about serialisation of data objects trees and/or change summaries? Regards Simon
