I have opened *TUSCANY-1048<https://issues.apache.org/jira/browse/TUSCANY-1048> * to track this topic.
The initial drop of the cts code had some contributions from Brian Murray and myself. I have made some significant modifications to these which I hope will better fit into the framework. The work is not complete but is complete enough to get some feedback on what features etc would be desirable in the CTS. - Paramatized test suite. Tests API calls and scenarios using Junit 4.1paramatized test runner to use DataObjects created and populated using different mechanisms - Application Server Test harness and application. Application UI using DOJO to categorize and present errors within a jsp for tests that have been executed within the application server environement rather than within a simple standalone java env. - Use TestHelper which in turn used HelperProvider to get instance of commonj.sdo.helper.* classes. I will attach source to the JIRA and continue this discussion there where appropiate. Robbie On 1/11/07, Robbie Minshall <[EMAIL PROTECTED]> wrote:
I would lean towards providing an exucutable jar file and a structure that allows for vendors to have their own branch/pom.xml for vendor specific implementations ( static code, TestHelperImpl etc ) and a dependancy on the cts ( java/cts/sdo21 java/cts/vendorImpl/tuscany or something). However, I am not sure off the top of my head if that would work well with the surefire plugin for maven. I personally prefer and use ant so will ultmately just be pulling in the cts jar into my own build env. Robbie On 1/9/07, Dan Murphy <[EMAIL PROTECTED]> wrote: > > Hi, > > I would like to get people's thoughts on how we want to launch the SDO > test > suite. As you may have seen, an initial set of tests have been committed > via > jira 987 < http://issues.apache.org/jira/browse/TUSCANY-987>. > > Since the tests are the "product" of the CTS suite, they are in the > /src/main/ folder. As I'm sure you know this means that they will be > built > into a jar when the default mvn build is run. > > Currently the pom does not actually attempt to run the CTS against any > implementation. Personally I think this is the right default behaviour, > if > it was to run the CTS against Tuscany by default it would add a > dependency > to tuscany and download it - which kind of goes against the idea of > being > implementation agnostic. > > However, people obviously do need to execute the CTS against an > implementation. We can do this a number of ways: > > 1. Provide commented out sections in the pom.xml that when > uncommented > would run against a given implementation (with Tuscany as an example) > 2. Provide seperate, alternative pom's that run against given > implementations; for example mvn -f tuscany.xml to run against > Tuscany > 3. Provide an executable jar that contains a launcher such that a > java > -jar sdo2.1-cts-1.0-SNAPSHOT.jar would execute the test suites (and > leave it to the user to put an implementation on their classpath) > 4. Provide a set of shell script to launch the tests (for Windows and > unix/linux) > > My personal preference is 2 (and is seems easier than 3 & 4) but not > sure if > this approach would be acceptable for other implementations. > Anyone got an opinion of how they would like to launch/execute the tests > ? > > Cheers, > Dan > > -- * * * 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
-- * * * 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
