You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@tuscany.apache.org by Dan Murphy <dm...@googlemail.com> on 2006/12/11 15:06:06 UTC

Re: Proposal for a (Java) community test suite for SDO

Hi Kelvin,
Thanks for creating the component for Jiras... I agree we need to amend the
names to cope with different spec / implementation versions

We need to agree on:

   - SVN module - propose java/cts/sdo2.1
      - allow for java/cts/sdo30 & java/cts/sca (if needed) in the
      future
      - Java package - propose test.sdo21
      - allows for test.sdo30 / test.sca.096 (if needed) in the future
   - How to easily link between test cases (or suite) and sections in the
   spec - propose package conversion of test.sdo21.section.subsection
      - eg. package test.sdo21.api.datagraph for tests relating to the
      Java API (main section) DataGraph (minor section) of the spec (section
      3.2)
      - another eg. test.sdo21.typeconv for the DataTypes Conversion
      section (section 16)
      - Using test.sdo21.section.subsection makes it easy to link
      cases to spec, but might be a little overkill - any thoughts ?
   - Where to locate SDO 2.1.0 Java Classes - propose linking to tuscany
   sdo spec project
      - Link to existing ones in Tuscany (in java/spec/sdo-api), or
      - package own copy
   - Framework to use - JUnit or the approach Robbie has, or some other ?
   - need to ensure sdo implementation is pluggable

Now that we have a Jira component (SDO Community Tests) I guess we can start
opening up new features against it and identifying what we have - if there
is an existing large suit / contribution then we could always just adopt its
approach (to start with).

Cheers,
Dan

Re: Proposal for a (Java) community test suite for SDO

Posted by Robbie Minshall <my...@gmail.com>.
Sorry I disappeared there . . . had a little run in with some bad fish ;-(

I uploaded our test case scenarios as attachments.  I would not recomend
doing anything with these for a week or so as I am going to take a look at
them myself and rework them a bit.  However, I uploaded them so that people
can look at the tests being performed if desired.   As mentioned we had our
test cases seperated from our junit wrappers so that we could easily execute
them from from within application servers without using junit framework.
TestCases then wrap scenario calls and handle exceptions as failures.

I took a look at Junit 4.1 today and converted a scneario to a 4.1 test
case.  I prototyped the ability to run within a custom harness which handles
failures for a particular environment ( just used System.out but will work
nicely within AppServer using webpage report ).  Attempted to use a
paramatized test runner so that DataObjects created in a variety of ways
could be passed into the same test method but this did not work due to some
TypeHelper scoping, for now I will just have a configuration which indicates
what type of DataObject creation should be used and execute the test case
within new JVM for each creation method.

So Junit 4.1 should work well for me and I will do some work to convert the
rest of the test cases if that seems like the right direction to others.

Source for test cases :
http://issues.apache.org/jira/secure/attachment/12347228/oldTestCases.zip

Conversion of a single scneario to junit 4.1:
http://issues.apache.org/jira/secure/attachment/12347229/convertedJunit41.zip

Robbie.






On 12/12/06, kelvin goodson <ke...@gmail.com> wrote:
>
> Dan,
>   I have opened TUSCANY-987 to cover the creation of the project
> structure.
> Would you be able to work on this and submit a patch? I'd be happy to
> commit
> it.
>
> Cheers, Kelvin.
>
> On 11/12/06, Dan Murphy <dm...@googlemail.com> wrote:
> >
> > Hi Kelvin,
> > Thanks for creating the component for Jiras... I agree we need to amend
> > the
> > names to cope with different spec / implementation versions
> >
> > We need to agree on:
> >
> >    - SVN module - propose java/cts/sdo2.1
> >       - allow for java/cts/sdo30 & java/cts/sca (if needed) in the
> >       future
> >       - Java package - propose test.sdo21
> >       - allows for test.sdo30 / test.sca.096 (if needed) in the future
> >    - How to easily link between test cases (or suite) and sections in
> the
> >    spec - propose package conversion of test.sdo21.section.subsection
> >       - eg. package test.sdo21.api.datagraph for tests relating to the
> >       Java API (main section) DataGraph (minor section) of the spec
> > (section
> >       3.2)
> >       - another eg. test.sdo21.typeconv for the DataTypes Conversion
> >       section (section 16)
> >       - Using test.sdo21.section.subsection makes it easy to link
> >       cases to spec, but might be a little overkill - any thoughts ?
> >    - Where to locate SDO 2.1.0 Java Classes - propose linking to tuscany
> >    sdo spec project
> >       - Link to existing ones in Tuscany (in java/spec/sdo-api), or
> >       - package own copy
> >    - Framework to use - JUnit or the approach Robbie has, or some other
> ?
> >    - need to ensure sdo implementation is pluggable
> >
> > Now that we have a Jira component (SDO Community Tests) I guess we can
> > start
> > opening up new features against it and identifying what we have - if
> there
> > is an existing large suit / contribution then we could always just adopt
> > its
> > approach (to start with).
> >
> > 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

Re: Proposal for a (Java) community test suite for SDO

Posted by kelvin goodson <ke...@gmail.com>.
Dan,
  I have opened TUSCANY-987 to cover the creation of the project structure.
Would you be able to work on this and submit a patch? I'd be happy to commit
it.

Cheers, Kelvin.

On 11/12/06, Dan Murphy <dm...@googlemail.com> wrote:
>
> Hi Kelvin,
> Thanks for creating the component for Jiras... I agree we need to amend
> the
> names to cope with different spec / implementation versions
>
> We need to agree on:
>
>    - SVN module - propose java/cts/sdo2.1
>       - allow for java/cts/sdo30 & java/cts/sca (if needed) in the
>       future
>       - Java package - propose test.sdo21
>       - allows for test.sdo30 / test.sca.096 (if needed) in the future
>    - How to easily link between test cases (or suite) and sections in the
>    spec - propose package conversion of test.sdo21.section.subsection
>       - eg. package test.sdo21.api.datagraph for tests relating to the
>       Java API (main section) DataGraph (minor section) of the spec
> (section
>       3.2)
>       - another eg. test.sdo21.typeconv for the DataTypes Conversion
>       section (section 16)
>       - Using test.sdo21.section.subsection makes it easy to link
>       cases to spec, but might be a little overkill - any thoughts ?
>    - Where to locate SDO 2.1.0 Java Classes - propose linking to tuscany
>    sdo spec project
>       - Link to existing ones in Tuscany (in java/spec/sdo-api), or
>       - package own copy
>    - Framework to use - JUnit or the approach Robbie has, or some other ?
>    - need to ensure sdo implementation is pluggable
>
> Now that we have a Jira component (SDO Community Tests) I guess we can
> start
> opening up new features against it and identifying what we have - if there
> is an existing large suit / contribution then we could always just adopt
> its
> approach (to start with).
>
> Cheers,
> Dan
>
>