You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Robbie Minshall <my...@gmail.com> on 2007/01/11 22:34:32 UTC
Re: [SDO CTS] addition of paramatized tests, application server harness
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 <my...@gmail.com> 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 <dm...@googlemail.com> 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/83388211@N00/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/83388211@N00/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
Re: [SDO CTS] addition of paramatized tests, application server harness
Posted by Dan Murphy <dm...@googlemail.com>.
Copy thread back to dist lists....
On 15/01/07, Dan Murphy <dm...@googlemail.com> wrote:
>
> Hi Robbie,
> Was planning to take a look at your recent jiras tomorrow (was a little
> too busy last week) - I've just created a patch for one of the RW test
> classes (though may refactor it to follow similar lines to the other
> scenario tests).
>
> So far, I've not needed to use SDOUtil and I'd like to keep it this way
> 2.1 seems to remove most of the need for it... problem is that any SDOUtil
> dependent code would need to go into another directory (with separate pom)
> otherwise anyone building the CTS may inadvertently download Tuscany classes
> (which is not really desired, IMHO).
> Cheers,
>
> On 15/01/07, Robbie Minshall <my...@gmail.com> wrote:
> >
> > Hey Dan.
> >
> > Should I go ahead and create a patch for the CTS. I think that the
> > biggest issue that should probably be discussed is the additions to,and
> > removal of tuscany implementation of TestHelper.
> > - Should be a seperation similar to spec and impl where the test classes
> > and framework does not rely on tuscany classes like SDOUtil.
> > perhaps something like : java/cts.<vendor>/sdo21
> > - Perhaps there should be a refactoring of TestHelper interface so that
> > there is a util class for things that will be common across vendors and
> > things that are very vendor specific like static sdo generation.
> >
> > I will take a look at the rougue wave patch this afternoon.
> >
> > Robbie
> >
> >
> >
> > On 1/15/07, kelvin goodson < kelvingoodson@gmail.com> wrote:
> > >
> > > Hi Robbie,
> > > Dan's the main man on this CTS stuff now. I'll still keep
> > > committing stuff when necessary, and chip in if it's appropriate, but I'm
> > > not going to get a chance to review your new stuff in detail any time soon.
> > >
> > > Cheers, Kelvin.
> > >
> > >
> > > On 15/01/07, Robbie Minshall < mykiwi@gmail.com> wrote:
> > > >
> > > > Dan, Kelvin have you had a chance to look at some of the changes to
> > > > the organization and the use of use of junit 4.1 features. Any more
> > > > thoughts on vendor specific initialization and staitc SDO testing ?
> > > >
> > > > If you like the general format of hte paramatized tests then I will
> > > > spend some time needed to clean it up and create a 'patch' for what is
> > > > currently in the java/cts branch. If there are suggestions, or especially
> > > > reorganization issues then lets discuss them.
> > > >
> > > > cheers,
> > > > Robbie
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 1/11/07, Robbie Minshall < mykiwi@gmail.com> wrote:
> > > > >
> > > > > 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.1 paramatized 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 <mykiwi@gmail.com > 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 < dm.subs@googlemail.com> 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 CTSagainst 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/83388211@N00/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/83388211@N00/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/83388211@N00/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/83388211@N00/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
> >
>
>
Re: [SDO CTS] addition of paramatized tests, application server harness
Posted by Dan Murphy <dm...@googlemail.com>.
Copy thread back to dist lists....
On 15/01/07, Dan Murphy <dm...@googlemail.com> wrote:
>
> Hi Robbie,
> Was planning to take a look at your recent jiras tomorrow (was a little
> too busy last week) - I've just created a patch for one of the RW test
> classes (though may refactor it to follow similar lines to the other
> scenario tests).
>
> So far, I've not needed to use SDOUtil and I'd like to keep it this way
> 2.1 seems to remove most of the need for it... problem is that any SDOUtil
> dependent code would need to go into another directory (with separate pom)
> otherwise anyone building the CTS may inadvertently download Tuscany classes
> (which is not really desired, IMHO).
> Cheers,
>
> On 15/01/07, Robbie Minshall <my...@gmail.com> wrote:
> >
> > Hey Dan.
> >
> > Should I go ahead and create a patch for the CTS. I think that the
> > biggest issue that should probably be discussed is the additions to,and
> > removal of tuscany implementation of TestHelper.
> > - Should be a seperation similar to spec and impl where the test classes
> > and framework does not rely on tuscany classes like SDOUtil.
> > perhaps something like : java/cts.<vendor>/sdo21
> > - Perhaps there should be a refactoring of TestHelper interface so that
> > there is a util class for things that will be common across vendors and
> > things that are very vendor specific like static sdo generation.
> >
> > I will take a look at the rougue wave patch this afternoon.
> >
> > Robbie
> >
> >
> >
> > On 1/15/07, kelvin goodson < kelvingoodson@gmail.com> wrote:
> > >
> > > Hi Robbie,
> > > Dan's the main man on this CTS stuff now. I'll still keep
> > > committing stuff when necessary, and chip in if it's appropriate, but I'm
> > > not going to get a chance to review your new stuff in detail any time soon.
> > >
> > > Cheers, Kelvin.
> > >
> > >
> > > On 15/01/07, Robbie Minshall < mykiwi@gmail.com> wrote:
> > > >
> > > > Dan, Kelvin have you had a chance to look at some of the changes to
> > > > the organization and the use of use of junit 4.1 features. Any more
> > > > thoughts on vendor specific initialization and staitc SDO testing ?
> > > >
> > > > If you like the general format of hte paramatized tests then I will
> > > > spend some time needed to clean it up and create a 'patch' for what is
> > > > currently in the java/cts branch. If there are suggestions, or especially
> > > > reorganization issues then lets discuss them.
> > > >
> > > > cheers,
> > > > Robbie
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 1/11/07, Robbie Minshall < mykiwi@gmail.com> wrote:
> > > > >
> > > > > 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.1 paramatized 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 <mykiwi@gmail.com > 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 < dm.subs@googlemail.com> 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 CTSagainst 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/83388211@N00/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/83388211@N00/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/83388211@N00/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/83388211@N00/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
> >
>
>
Re: [SDO CTS] addition of paramatized tests, application server harness
Posted by Robbie Minshall <my...@gmail.com>.
Dan, Kelvin have you had a chance to look at some of the changes to the
organization and the use of use of junit 4.1 features. Any more thoughts on
vendor specific initialization and staitc SDO testing ?
If you like the general format of hte paramatized tests then I will spend
some time needed to clean it up and create a 'patch' for what is currently
in the java/cts branch. If there are suggestions, or especially
reorganization issues then lets discuss them.
cheers,
Robbie
On 1/11/07, Robbie Minshall <my...@gmail.com> wrote:
>
> 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 <my...@gmail.com> 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 < dm.subs@googlemail.com> 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/83388211@N00/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/83388211@N00/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/83388211@N00/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
Re: [SDO CTS] addition of paramatized tests, application server harness
Posted by Robbie Minshall <my...@gmail.com>.
Dan, Kelvin have you had a chance to look at some of the changes to the
organization and the use of use of junit 4.1 features. Any more thoughts on
vendor specific initialization and staitc SDO testing ?
If you like the general format of hte paramatized tests then I will spend
some time needed to clean it up and create a 'patch' for what is currently
in the java/cts branch. If there are suggestions, or especially
reorganization issues then lets discuss them.
cheers,
Robbie
On 1/11/07, Robbie Minshall <my...@gmail.com> wrote:
>
> 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 <my...@gmail.com> 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 < dm.subs@googlemail.com> 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/83388211@N00/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/83388211@N00/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/83388211@N00/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