I agree that the tests should be structured in a way that is spec and functionaly orientated. I have never really liked the split between paramatized and non paramatized tests so getting rid of this is just fine.
Other than that I think that the test cases are more or less organized by API though I am sure some changes could be beneficial. The idea behind the paramatized tests does indeed lean towards consistency. In general the SDO API should apply regardless of the creation means for the DataObject ( static, dynamic, mixed, the old relational DB DAS or any other datasource ). This is done simply by injecting a dataObject instance into a common set of tests. However, I don't think that this should be packaged under a consistency package - for me that has the same problems as being organized under paramatized where you do not get a feel for complete API coverage. If you want to get ride of that problem you should just have a single source tree organized by API and have both paramatized and non paramatized tests in that single tree. I would note that while slightly diluted ( moved more to an interface to XML with the lack of work on the RDB DAS ) the intial conception of SDO as a common API to many datasources shoudl still be maintained. In my view this means that API tests etc should be performed on a variety of dataobject creation mechanisms and paramatized tests are the way to go. cheers, Robbie. On 5/1/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
Having spent some time getting to grips with the CTS there are some things I think I'd like to improve. First amongst them is to get some structure that allows us to get a feel for how well the spec is covered by the tests. One thing that concerns me is that one of the most apparent things in the structure is the split between the parameterized and the "single shot" junit tests. This seems like a junit technology driven split, and I don't think it is necessary or desirable. We should be able to apply the parameterization feature of junit without it being so prominent in the source code structure. I'd like to see more relation between spec features and test code packaging. That way we are more likely to spot gaps or overlaps. I feel sure that this will throw up some other issues, like testing certain features in combination. As a first step I'd like to propose refactoring the "paramatized" package. As far as I can see our usage of the junit parameterized testing function is aimed at ensuring consistency between operations performed on graphs when the metadata has been produced a) from an xsd and b) by using the SDO API to create it dynamically. I propose to rehouse these under test.sdo21.consistency. -- Kelvin.
-- * * * 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
