You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tuscany.apache.org by kelvin goodson <ke...@thegoodsons.org.uk> on 2007/04/16 15:41:46 UTC

[Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Hi,
 I'm looking at doing some work in the CTS. I was looking back at Robbie's
attached description about how to keep the tests "harness agnostic".  I'm
assuming that this is still a goal of the CTS although I may have missed
something in my catching up. In my quest to make the CTS better I note that
a number of the test case classes still extend the junit TestCase class.
This is true for all test classes that have a setUp() method. One that
doesn't inherit from TestCase is XSDSerializationTest,  and adding a setUp
method to this class doesn't cause junit to invoke it in my eclipse
environment. I'm trying to work out whether I should I expect a
4.1environment to discover and execute the setUp method when junit is
used in
this way. I seem to have Eclipse junit plugins for 3.8.1 and 4.1.0.1 and the
preferences tab for Junit doesn't seem to offer much in the way of
configuration, so I can't be sure I'm using 4.1 behaviour.

I really would like to be XSDSerializationTests to execute setUp so that we
can have a fresh HelperContext per test,  and I guess the easy way out is to
make the test class inherit from TestCase like the others,  but I'd prefer
not to introduce the explicit dependency on Junit if I can avoid it.

Regards Kelvin.


On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
>
> This sounds quite good.
>
> I have written some test cases with Brian Murray which I would be happy to
> contribute to tuscany.  Identifying duplication and differences in similar
> tests would probably be an intersting excercise right off the bat.
>
> One decision that we spent a little time mulling over was the framework to
> use for our test suite.  Originally we used the much loved junit harness
> which worked well.  Different runtimes ( command line, J2EE Application
> Server, a Service Container ) have different classloader hierarchies etc.
> Without many modifications to the junit code it was difficult and quite ugly
> testing SDO within the context of a variety of runtimes which the SDO APIs
> will be used.
>
> We took the approach of writing general test libraries which can then
> simply be called from a variety of test frameworks such as junit or a simple
> J2EE or SCA Application test harness.  I like this approach for keeping the
> actual test code very simple, allowing for integration a variety of test
> frameworks, and providing ability to test directly within the different
> runtimes people care about.
>
> Any thoughts on this ?
>
> Robbie
>
>
>
>
> On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> >
> > Andy,
> >   please attach them to the JIRA for this work and one of us can pick
> > them
> > up, thanks.
> > Best Regards, Kelvin.
> >
> > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com> wrote:
> > >
> > >
> > > Hi Dan,
> > >
> > > I was previously working with Kelvin Goodson to donate some junit
> > tests
> > > on behalf of Rogue Wave Software.
> > >
> > > These tests are written purely to the SDO API and I have validated
> > that
> > > the tests do run against Tuscany as well as Rogue Wave's
> > implementation.
> > >
> > >
> > > Should I send the tests to Kelvin?
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > -----Original Message-----
> > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > Sent: 30 November 2006 17:44
> > > To: Tuscany Developers; Tuscany Users
> > > Subject: Proposal for a (Java) community test suite for SDO
> > >
> > > 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
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> * * * 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: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

Hi Simon, 

By using the @Before annotation on the setup method and the @Test
annotation on test methods means the test case no longer needs to extend
TestCase and that in turn means that the setUp/teardown methods can be
made public rather than protected, which removes one of the barriers of
using standard junit test classes from another harness, while still
allowing them to be used as native junit tests.

With public methods it is possible to use reflection to load the test
case and then call the setup / test / teardown methods in turn. There is
still a dependency on junit.jar but no dependency on the junit test
runner class.

Hope that helps.

Andy.

-----Original Message-----
From: Simon Nash [mailto:nash@hursley.ibm.com] 
Sent: 17 April 2007 14:35
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

If the goal is to make the tests "harness agnostic", then I don't see
much difference between a JUnit-specific inheritance dependency and a
JUnit-specific annotation dependency.  Is the annotation dependency less
troublesome for some reason?

   Simon

kelvin goodson wrote:

> Thanks for this Andy,  I'll play with it tomorrow.
> 
> Regards, Kelvin.
> 
> On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> 
>>
>>
>> I believe you just need to annotate the setUp method with @Before. 
>> This is described in the junit cookbook, here:
>>
>> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
>>
>> I'm currently working on submitting some more XSD test cases in the 
>> CTS so I'll try this method out. Hopefully I can then remove the 
>> current dependency on TestCase in those tests.
>>
>> Thanks,
>>
>> Andy.
>>
>>
>> -----Original Message-----
>> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On 
>> Behalf Of kelvin goodson
>> Sent: 16 April 2007 14:42
>> To: tuscany-dev@ws.apache.org
>> Cc: Robbie Minshall
>> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
>> classes don't inherit from TestCase
>>
>> Hi,
>> I'm looking at doing some work in the CTS. I was looking back at 
>> Robbie's attached description about how to keep the tests "harness 
>> agnostic".  I'm assuming that this is still a goal of the CTS 
>> although I may have missed something in my catching up. In my quest 
>> to make the CTS better I note that a number of the test case classes 
>> still extend the junit TestCase class.
>> This is true for all test classes that have a setUp() method. One 
>> that doesn't inherit from TestCase is XSDSerializationTest,  and 
>> adding a setUp method to this class doesn't cause junit to invoke it 
>> in my eclipse environment. I'm trying to work out whether I should I 
>> expect a 4.1environment to discover and execute the setUp method when

>> junit is used in this way. I seem to have Eclipse junit plugins for 
>> 3.8.1 and
>> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much 
>> in the way of configuration, so I can't be sure I'm using 4.1
behaviour.
>>
>> I really would like to be XSDSerializationTests to execute setUp so 
>> that we can have a fresh HelperContext per test,  and I guess the 
>> easy way out is to make the test class inherit from TestCase like the

>> others, but I'd prefer not to introduce the explicit dependency on 
>> Junit if I can avoid it.
>>
>> Regards Kelvin.
>>
>>
>> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
>> >
>> > This sounds quite good.
>> >
>> > I have written some test cases with Brian Murray which I would be 
>> > happy to contribute to tuscany.  Identifying duplication and 
>> > differences in similar tests would probably be an intersting 
>> > excercise
>> right off the bat.
>> >
>> > One decision that we spent a little time mulling over was the 
>> > framework to use for our test suite.  Originally we used the much 
>> > loved junit harness which worked well.  Different runtimes ( 
>> > command line, J2EE Application Server, a Service Container ) have 
>> > different
>> classloader hierarchies etc.
>> > Without many modifications to the junit code it was difficult and 
>> > quite ugly testing SDO within the context of a variety of runtimes 
>> > which the SDO APIs will be used.
>> >
>> > We took the approach of writing general test libraries which can 
>> > then simply be called from a variety of test frameworks such as 
>> > junit or a simple J2EE or SCA Application test harness.  I like 
>> > this approach for
>>
>> > keeping the actual test code very simple, allowing for integration 
>> > a variety of test frameworks, and providing ability to test 
>> > directly within the different runtimes people care about.
>> >
>> > Any thoughts on this ?
>> >
>> > Robbie
>> >
>> >
>> >
>> >
>> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
>> > >
>> > > Andy,
>> > >   please attach them to the JIRA for this work and one of us can 
>> > > pick them up, thanks.
>> > > Best Regards, Kelvin.
>> > >
>> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com> wrote:
>> > > >
>> > > >
>> > > > Hi Dan,
>> > > >
>> > > > I was previously working with Kelvin Goodson to donate some 
>> > > > junit
>> > > tests
>> > > > on behalf of Rogue Wave Software.
>> > > >
>> > > > These tests are written purely to the SDO API and I have 
>> > > > validated
>> > > that
>> > > > the tests do run against Tuscany as well as Rogue Wave's
>> > > implementation.
>> > > >
>> > > >
>> > > > Should I send the tests to Kelvin?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Andy.
>> > > >
>> > > > -----Original Message-----
>> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
>> > > > Sent: 30 November 2006 17:44
>> > > > To: Tuscany Developers; Tuscany Users
>> > > > Subject: Proposal for a (Java) community test suite for SDO
>> > > >
>> > > > 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
>> > > >
>> > > > ---------------------------------------------------------------
>> > > > ---
>> > > > --- To unsubscribe, e-mail: 
>> > > > tuscany-dev-unsubscribe@ws.apache.org
>> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > * * * 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@gmail.com>.

A quick correction on my previous note which reflects a bias towards the
junit 3.8 approach that I didn't really intend.


 some static code that performed any real startup overhead and cached the
> helper.  This all leads me to believing that to get true agnosticism wrt the
> test harness we should perhaps introduce bespoke function, some of which
> replicates the junit 4.1 features, either by creating an abstract
> specialization of TestCase or TestRunner or both.
>
>
We could of course introduce the generic test case behaviour for individual
test method set-up independent of the junit TestCase class.

Kelvin.

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@gmail.com>.

On the basis of the discussion above I just committed revision 532749 with
the following comment
===
I inserted an intermediate junit 3.8 style specific testcase class above
DataObjectListTest (and propose to do this for others).  The intermediate
class delegates much function off to a non junit 3.8 specific class.  So now
any 4.1 style test classes can inherit from the non-junit superclass,  and
the junit 3.8 style ones can use the junit specific ones.  This allows us to
1) promote setUp/tearDown to public to promote test harness agnosticism, 2)
ensure that the testHelper has been initialized once per setUp() call,
thereby permitting runs of individual tests, 3) do standard setup stuff such
as create a HelperContext per test execution.

I also moved the DataObjectListTest to the Approved set
===

So this fixes some niggles centrally (cross talk due to HelperContext reuse,
and running small sets/individual tests) and allows us to promote harness
agnosticism while carry on with a hybrid approach to the junit style.  We
can readily switch classes between approaches if we decide to converge on a
single approach at some time.  I propose to adjust all test classes this way
as i go through them,  and eventually do away with the static TestHelper
instance in the CTSSuite class.

Kelvin.

On 20/04/07, Frank Budinsky <fr...@ca.ibm.com> wrote:
>
> I agree.
>
> Frank.
>
> "Andy Grove" <gr...@roguewave.com> wrote on 04/20/2007 01:14:51 PM:
>
> >
> > I would certainly prefer to continue with junit.
> >
> > There are frameworks such as cactus, that allow junit tests to be run in
> > J2EE environments, and if vendors need the ability to run the tests in
> > some other environment that is not supported by junit or cactus then
> > they always have the option of developing their own test runners or
> > tweaking the junit code to fit their requirements. This does seem like
> > an edge case and it would seem appropriate for those users to invest the
> > effort to solve the problem rather than putting an extra burden on
> > developing the general purpose CTS.
> >
> > Thanks,
> >
> > Andy.
> >
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 20 April 2007 17:19
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes don't inherit from TestCase
> >
> > The Junit tooling is so useful I'd be loath to drop it as the harness
> > that the Tuscany implementation uses for exercising the tests. I'm going
> > to do a bit of playing to see what solutions are practical,  but I'm
> > concerned that we may be considering putting significant effort into a
> > goal that's rather too theoretical, as junit seems so ubiquitous.
> >
> > Regards, Kelvin.
> >
> > On 20/04/07, Andy Grove < grove@roguewave.com> wrote:
> > <snip/>
> >
> > One option is to stop using junit completely and replicate the useful
> > > features in a minimal test framework that supports parameterized tests
> >
> > > e.g. we could introduce a CTSTestCase interface:
> > >
> > >
> > > <snip/>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Frank Budinsky <fr...@ca.ibm.com>.

I agree.

Frank.

"Andy Grove" <gr...@roguewave.com> wrote on 04/20/2007 01:14:51 PM:

> 
> I would certainly prefer to continue with junit.
> 
> There are frameworks such as cactus, that allow junit tests to be run in
> J2EE environments, and if vendors need the ability to run the tests in
> some other environment that is not supported by junit or cactus then
> they always have the option of developing their own test runners or
> tweaking the junit code to fit their requirements. This does seem like
> an edge case and it would seem appropriate for those users to invest the
> effort to solve the problem rather than putting an extra burden on
> developing the general purpose CTS.
> 
> Thanks,
> 
> Andy. 
> 
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com] 
> Sent: 20 April 2007 17:19
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
> 
> The Junit tooling is so useful I'd be loath to drop it as the harness
> that the Tuscany implementation uses for exercising the tests. I'm going
> to do a bit of playing to see what solutions are practical,  but I'm
> concerned that we may be considering putting significant effort into a
> goal that's rather too theoretical, as junit seems so ubiquitous.
> 
> Regards, Kelvin.
> 
> On 20/04/07, Andy Grove < grove@roguewave.com> wrote:
> <snip/>
> 
> One option is to stop using junit completely and replicate the useful
> > features in a minimal test framework that supports parameterized tests
> 
> > e.g. we could introduce a CTSTestCase interface:
> >
> >
> > <snip/>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

I would certainly prefer to continue with junit.

There are frameworks such as cactus, that allow junit tests to be run in
J2EE environments, and if vendors need the ability to run the tests in
some other environment that is not supported by junit or cactus then
they always have the option of developing their own test runners or
tweaking the junit code to fit their requirements. This does seem like
an edge case and it would seem appropriate for those users to invest the
effort to solve the problem rather than putting an extra burden on
developing the general purpose CTS.

Thanks,

Andy. 

-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com] 
Sent: 20 April 2007 17:19
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

The Junit tooling is so useful I'd be loath to drop it as the harness
that the Tuscany implementation uses for exercising the tests. I'm going
to do a bit of playing to see what solutions are practical,  but I'm
concerned that we may be considering putting significant effort into a
goal that's rather too theoretical, as junit seems so ubiquitous.

Regards, Kelvin.

On 20/04/07, Andy Grove < grove@roguewave.com> wrote:
<snip/>

One option is to stop using junit completely and replicate the useful
> features in a minimal test framework that supports parameterized tests

> e.g. we could introduce a CTSTestCase interface:
>
>
> <snip/>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@gmail.com>.

The Junit tooling is so useful I'd be loath to drop it as the harness that
the Tuscany implementation uses for exercising the tests. I'm going to do a
bit of playing to see what solutions are practical,  but I'm concerned that
we may be considering putting significant effort into a goal that's rather
too theoretical, as junit seems so ubiquitous.

Regards, Kelvin.

On 20/04/07, Andy Grove < grove@roguewave.com> wrote:
<snip/>

One option is to stop using junit completely and replicate the useful
> features in a minimal test framework that supports parameterized tests
> e.g. we could introduce a CTSTestCase interface:
>
>
> <snip/>

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

When we talk about being "test-harness agnostic", I think we're really
saying "not dependent on junit" due to complexities that junit
introduces.

One option is to stop using junit completely and replicate the useful
features in a minimal test framework that supports parameterized tests
e.g. we could introduce a CTSTestCase interface:

interface CTSTestCase {

  void setup();

  void teardown();

  /** parameterized testing */
  void setData(Object data);

}

It would then be simple enough to have a TestRunner to invoke classes
that implement this interface. 

The advantage of this approach is that it enforces some constraints on
the complexity of the tests. If we use junit directly then we might end
up introducing dependencies on more junit features that are hard to
replicate in other test harnesses.

We could replicate the junit Assert class and use a static import so the
test code itself still looks the same as junit test case e.g. calling
assertEquals() and fail().

Andy.



-----Original Message-----
From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On Behalf
Of kelvin goodson
Sent: 20 April 2007 10:15
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

I'd agree in general that it's the naming convention that would be key
to readily being able to exercise the tests by another framework.
With regards to refactoring the parameterized tests, I like the concept
of being able to have a battery of data sets that can be used to
exercise tests.  Maybe we can put in place some simple bespoke function
for this kind of behaviour.  I've had this in the back of my mind while
looking at the code.

Another compilcation is that there's no precedent in junit 3.8 for the
@BeforeClass type of calls, which some of the new tests are using, so
we'll need to establish a convention for that.

A frustration that I find is that the current structure doesn't permit
running/debugging individual tests. If you want breakpoints deep in the
SDO /EMF code and then have to run 50 tests before getting to the one
you are interested in then that's a bit of a pain. Often in eclipse in
the SDO implementation tests,  I right click in the Junit panel on a
failing test and click run/debug, to exercise a single failing test. I
think the restriction is introduced into the CTS primarily because of
the one time
initialization of the implementation specific test helper.   I would
imagine
it could be very low cost to initialize this once per setUp() in a
superclass, the first initialization triggering some static code that
performed any real startup overhead and cached the helper.  This all
leads me to believing that to get true agnosticism wrt the test harness
we should perhaps introduce bespoke function, some of which replicates
the junit 4.1features, either by creating an abstract specialization of
TestCase or TestRunner or both.

--
Kelvin

On 20/04/07, Andy Grove <gr...@roguewave.com> wrote:
>
>
> Just for clarification, I think we're saying that the important thing 
> here is the method naming convention, rather than requiring the tests 
> to extend TestCase?
>
> If we follow the junit 3.8 naming convention and always use the method

> names setUp / teardown (and make sure they are public methods) and 
> have all test methods start with "test" then it won't matter if the 
> tests extend TestCase or have junit 4.1 annotations.
>
> However, just to complicate matters, the tests in the 
> parameterizedTests package are making use of new junit 4.1 features 
> for providing parameters to the tests and these tests don't currently 
> fit into the simple junit 3.8 style and it will be much harder to 
> re-use these tests from other frameworks in their current form. If we 
> want to stick to the simple junit 3.8 style then these tests will need
some refactoring.
>
> Regards,
>
> Andy.
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 19 April 2007 11:03
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
> classes don't inherit from TestCase
>
> In fact I'd say for the purposed of introspection by some other 
> harness the old style is far preferable,  since it's easy to  examine 
> the method names/signatures to determine what is a test and what is a
setup method.
> I was about to start cleaning these up,  but I'd like to complete this

> discussion and decide whether we should be making everything use the 
> old 3.8style or the new
> 4.1 annotations.  What I will do in the meantime is add setup methods 
> to all the files in their existing style in order to fix up the issues

> with reusing type helpers between tests, and then revisit the style 
> after the discussion has completed.  For simplicity I will use the 
> same method signatures for setup methods as are used in 3.8 when using

> 4.1 annotations.
>
> Regards, Kelvin.
>
>
> On 18/04/07, Andy Grove <gr...@roguewave.com> wrote:
> >
> >
> > Frank,
> >
> > You're absolutely right. I guess I'd forgotten that you could 
> > override
>
> > a protected method and make it public.
> >
> > In that case, it doesn't seem to matter if we use "old-style" junit 
> > or
>
> > annotations - it should still be possible to call the tests without 
> > using the junit test runners.
> >
> > Andy.
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 17 April 2007 18:01
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when

> > classes don't inherit from TestCase
> >
> > Hi Andy,
> >
> > Java allows you make something more visible in a derived class than 
> > in
>
> > the base, so declaring setUp() public in MyTest wouldn't seem to be 
> > a problem.
> >
> >
> > Frank
> >
> > "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 12:19:37 PM:
> >
> > > Hi Frank,
> > >
> > > The TestCase class defines setUp and tearDown as protected 
> > > methods, forcing the child class to also declare them as protected

> > > methods and this means they can't be loaded using reflection.
> > >
> > > Using junit 4.1 means we can declare the methods as public.
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 17 April 2007 17:03
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp 
> > > when
>
> > > classes don't inherit from TestCase
> > >
> > > Hi Andy,
> > >
> > > Maybe this is a stupid question (my junit ignorance showing 
> > > through
> > :-),
> > > but couldn't you have run your simple test harness (main) even if
> > MyTest
> > > extended from TestCase? Is there something about having the base 
> > > class that prevents you from simply invoking the test methods
> directly?
> > >
> > > Frank.
> > >
> > > "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49
AM:
> > >
> > > >
> > > > To better understand this myself, I just put a simple test case 
> > > > together using junit 4.1 with annotations and made use of the 
> > > > junit assertion calls e.g.
> > > >
> > > > public class MyTest {
> > > >     @Test
> > > >     public void testSomething() {
> > > >         // this test will fail
> > > >         assertEquals( "numbers are same", 1, 2 );
> > > >     }
> > > > }
> > > >
> > > > I then wrote a simple test harness to load the test class using 
> > > > reflection and invoke any methods starting with "test".
> > > >
> > > >  public static void main(String[] args) throws Exception {
> > > >         Class testClass = Class.forName( "test.MyTest" );
> > > >         Object testObject = testClass.newInstance();
> > > >         Method method[] = testClass.getMethods();
> > > >         for (int i = 0; i < method.length; i++) {
> > > >             if (method[i].getName().startsWith("test")) {
> > > >                 System.out.println("Running " +
> > method[i].getName());
> > > >                 try {
> > > >                     method[i].invoke( testObject );
> > > >                 } catch (Throwable th) {
> > > >                     th.printStackTrace();
> > > >                 }
> > > >             }
> > > >         }
> > > >     }
> > > >
> > > > This ran the above test method and caught the following
exception:
> > > >
> > > > java.lang.AssertionError: numbers are same expected:<1> but 
> > > > was:<2>
> > > >
> > > > For me, this seems to demonstrate that using junit 4.1 style 
> > > > tests
>
> > > > will allow people to call their tests from their own test 
> > > > harnesses without requiring junit-users to have to go to any
> special effort.
> > The
> > >
> > > > junit
> > > > Assert.* methods simply check some criteria and then call fail()

> > > > if that criteria is false. The fail() method simply throws an
> > > AssertionError.
> > > >
> > > > Writing the CTS tests using junit with annotations (rather than 
> > > > extending TestCase) does seem to provide everything required to
> > allow
> > > > users to run the tests outside of junit, albeit with a 
> > > > dependency on
> >
> > > > junit.jar but I don't see why that would be a problem for
anyone?
> > > > We
> >
> > > > could write our own versions of the assert* methods but they 
> > > > would
> > do
> > > > exactly the same thing as the junit implementation so this seems

> > > > rather pointless.
> > > >
> > > > My conclusion is that we should continue writing SDO CTS tests 
> > > > using
> >
> > > > junit, but ensure we use the annotation pattern rather than
> > extending
> > > > TestCase. Is everyone happy with this?
> > > >
> > > > Thanks,
> > > >
> > > > Andy.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: 17 April 2007 14:53
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp 
> > > > when
> >
> > > > classes don't inherit from TestCase
> > > >
> > > > Yes, I was about to write to the list on this subject. I'd like 
> > > > to
>
> > > > understand more of how the test harness agnosticism was 
> > > > intended,
> > and
> > > > whether its really practical. As it stands there is still junit 
> > > > through and through,  in particular, each test method still
> > references
> > >
> > > > junit assertion calls.  Even if we could do assertions from 
> > > > annotations (as per JML pre and post conditions),  we still have

> > > > all
> > > the junit imports.
> > > > If that were possible, then I guess each of the test methods 
> > > > could
> > be
> > > > invoked by something other than the junit test harness,  but 
> > > > they would have trouble asserting anything about the success of 
> > > > the
> > method
> > > > invocation,  since there are no artifacts available before or 
> > > > after the method invocation to make assertions about.
> > > >
> > > > Kelvin
> > > >
> > > > On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> > > > >
> > > > > If the goal is to make the tests "harness agnostic", then I 
> > > > > don't see much difference between a JUnit-specific inheritance
> > dependency
> > > > > and a JUnit-specific annotation dependency.  Is the annotation

> > > > > dependency less troublesome for some reason?
> > > > >
> > > > >    Simon
> > > > >
> > > > > kelvin goodson wrote:
> > > > >
> > > > > > Thanks for this Andy,  I'll play with it tomorrow.
> > > > > >
> > > > > > Regards, Kelvin.
> > > > > >
> > > > > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> I believe you just need to annotate the setUp method with
> > > @Before.
> > > > > >> This is described in the junit cookbook, here:
> > > > > >>
> > > > > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > > > > >>
> > > > > >> I'm currently working on submitting some more XSD test 
> > > > > >> cases in
> >
> > > > > >> the
> > > >
> > > > > >> CTS so I'll try this method out. Hopefully I can then 
> > > > > >> remove
> > the
> > > > > >> current dependency on TestCase in those tests.
> > > > > >>
> > > > > >> Thanks,
> > > > > >>
> > > > > >> Andy.
> > > > > >>
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: kelvingoodson@gmail.com 
> > > > > >> [mailto:kelvingoodson@gmail.com]
> > On
> > > > > Behalf
> > > > > >> Of kelvin goodson
> > > > > >> Sent: 16 April 2007 14:42
> > > > > >> To: tuscany-dev@ws.apache.org
> > > > > >> Cc: Robbie Minshall
> > > > > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp
> > when
> > > > > classes
> > > > > >> don't inherit from TestCase
> > > > > >>
> > > > > >> Hi,
> > > > > >> I'm looking at doing some work in the CTS. I was looking 
> > > > > >> back
> > at
> > > > > >> Robbie's attached description about how to keep the tests 
> > > > > >> "harness agnostic".  I'm assuming that this is still a goal

> > > > > >> of the CTS although
> > > > > I
> > > > > >> may have missed something in my catching up. In my quest to
> > make
> > > > > >> the
> > > > > CTS
> > > > > >> better I note that a number of the test case classes still
> > extend
> > >
> > > > > >> the junit TestCase class.
> > > > > >> This is true for all test classes that have a setUp()
method.
> > One
> > >
> > > > > >> that doesn't inherit from TestCase is XSDSerializationTest,
> > and
> > > > > >> adding a setUp method to this class doesn't cause junit to
> > invoke
> > >
> > > > > >> it in my eclipse environment. I'm trying to work out 
> > > > > >> whether I should I expect a 4.1environment to discover and 
> > > > > >> execute the setUp method when junit is used in this way. I 
> > > > > >> seem to have Eclipse junit
> > > >
> > > > > >> plugins for 3.8.1 and
> > > > > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to 
> > > > > >> offer
> >
> > > > > >> much in the way of configuration, so I can't be sure I'm 
> > > > > >> using
> > > > > >> 4.1
> > > > behaviour.
> > > > > >>
> > > > > >> I really would like to be XSDSerializationTests to execute
> > setUp
> > > > > >> so
> > > > > that
> > > > > >> we can have a fresh HelperContext per test,  and I guess 
> > > > > >> the
> > easy
> > >
> > > > > >> way out is to make the test class inherit from TestCase 
> > > > > >> like
> > the
> > > > > >> others, but I'd prefer not to introduce the explicit 
> > > > > >> dependency
> >
> > > > > >> on Junit if I can avoid it.
> > > > > >>
> > > > > >> Regards Kelvin.
> > > > > >>
> > > > > >>
> > > > > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > > > > >> >
> > > > > >> > This sounds quite good.
> > > > > >> >
> > > > > >> > I have written some test cases with Brian Murray which I
> > would
> > > > > >> > be
> > > >
> > > > > >> > happy to contribute to tuscany.  Identifying duplication 
> > > > > >> > and differences in similar tests would probably be an 
> > > > > >> > intersting
> > > > > excercise
> > > > > >> right off the bat.
> > > > > >> >
> > > > > >> > One decision that we spent a little time mulling over was

> > > > > >> > the
> >
> > > > > >> > framework to use for our test suite.  Originally we used 
> > > > > >> > the much
> > > >
> > > > > >> > loved junit harness which worked well.  Different 
> > > > > >> > runtimes ( command line, J2EE Application Server, a 
> > > > > >> > Service Container ) have
> > > >
> > > > > >> > different
> > > > > >> classloader hierarchies etc.
> > > > > >> > Without many modifications to the junit code it was 
> > > > > >> > difficult
> >
> > > > > >> > and
> > > >
> > > > > >> > quite ugly testing SDO within the context of a variety of

> > > > > >> > runtimes which the SDO APIs will be used.
> > > > > >> >
> > > > > >> > We took the approach of writing general test libraries 
> > > > > >> > which can then simply be called from a variety of test 
> > > > > >> > frameworks such as junit or a simple J2EE or SCA 
> > > > > >> > Application test
> > harness.
> > >
> > > > > >> > I like this approach
> > > > > for
> > > > > >>
> > > > > >> > keeping the actual test code very simple, allowing for 
> > > > > >> > integration a variety of test frameworks, and providing
> > ability
> > >
> > > > > >> > to test directly within the different runtimes people 
> > > > > >> > care
> > > about.
> > > > > >> >
> > > > > >> > Any thoughts on this ?
> > > > > >> >
> > > > > >> > Robbie
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com >
> wrote:
> > > > > >> > >
> > > > > >> > > Andy,
> > > > > >> > >   please attach them to the JIRA for this work and one 
> > > > > >> > > of
> > us
> > > > > >> > > can pick them up, thanks.
> > > > > >> > > Best Regards, Kelvin.
> > > > > >> > >
> > > > > >> > > On 01/12/06, Andy Grove (Contractor) 
> > > > > >> > > <gr...@roguewave.com>
> > > > wrote:
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > Hi Dan,
> > > > > >> > > >
> > > > > >> > > > I was previously working with Kelvin Goodson to 
> > > > > >> > > > donate
> > some
> > >
> > > > > >> > > > junit
> > > > > >> > > tests
> > > > > >> > > > on behalf of Rogue Wave Software.
> > > > > >> > > >
> > > > > >> > > > These tests are written purely to the SDO API and I 
> > > > > >> > > > have
> > > > > validated
> > > > > >> > > that
> > > > > >> > > > the tests do run against Tuscany as well as Rogue 
> > > > > >> > > > Wave's
> > > > > >> > > implementation.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > Should I send the tests to Kelvin?
> > > > > >> > > >
> > > > > >> > > > Thanks,
> > > > > >> > > >
> > > > > >> > > > Andy.
> > > > > >> > > >
> > > > > >> > > > -----Original Message-----
> > > > > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > > > >> > > > Sent: 30 November 2006 17:44
> > > > > >> > > > To: Tuscany Developers; Tuscany Users
> > > > > >> > > > Subject: Proposal for a (Java) community test suite 
> > > > > >> > > > for
> > SDO
> > > > > >> > > >
> > > > > >> > > > 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
> > > > > >> > > >
> > > > > >> > > >
> > > > > --------------------------------------------------------------
> > > > > --
> > > > > --
> > > > > >> > > > --- To unsubscribe, e-mail:
> > > > > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > >> > > > For additional commands, e-mail:
> > > > > >> > > > tuscany-dev-help@ws.apache.org
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > * * * 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
> > > > > >>
> > > > > >>
> > -----------------------------------------------------------------
> > > > > >> --
> > > > > >> -- To unsubscribe, e-mail:
> > tuscany-dev-unsubscribe@ws.apache.org
> > > > > >> For additional commands, e-mail:
> > > > > >> tuscany-dev-help@ws.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > --------------------------------------------------------------------
> > > > > - To unsubscribe, e-mail: 
> > > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: 
> > > > > tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > -
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > ------------------------------------------------------------------
> > > --
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@thegoodsons.org.uk>.

I'd agree in general that it's the naming convention that would be key to
readily being able to exercise the tests by another framework.
With regards to refactoring the parameterized tests, I like the concept of
being able to have a battery of data sets that can be used to exercise
tests.  Maybe we can put in place some simple bespoke function for this kind
of behaviour.  I've had this in the back of my mind while looking at the
code.

Another compilcation is that there's no precedent in junit 3.8 for the
@BeforeClass type of calls, which some of the new tests are using, so we'll
need to establish a convention for that.

A frustration that I find is that the current structure doesn't permit
running/debugging individual tests. If you want breakpoints deep in the SDO
/EMF code and then have to run 50 tests before getting to the one you are
interested in then that's a bit of a pain. Often in eclipse in the SDO
implementation tests,  I right click in the Junit panel on a failing test
and click run/debug, to exercise a single failing test. I think the
restriction is introduced into the CTS primarily because of the one time
initialization of the implementation specific test helper.   I would imagine
it could be very low cost to initialize this once per setUp() in a
superclass, the first initialization triggering some static code that
performed any real startup overhead and cached the helper.  This all leads
me to believing that to get true agnosticism wrt the test harness we should
perhaps introduce bespoke function, some of which replicates the junit
4.1features, either by creating an abstract specialization of TestCase
or
TestRunner or both.

--
Kelvin

On 20/04/07, Andy Grove <gr...@roguewave.com> wrote:
>
>
> Just for clarification, I think we're saying that the important thing
> here is the method naming convention, rather than requiring the tests to
> extend TestCase?
>
> If we follow the junit 3.8 naming convention and always use the method
> names setUp / teardown (and make sure they are public methods) and have
> all test methods start with "test" then it won't matter if the tests
> extend TestCase or have junit 4.1 annotations.
>
> However, just to complicate matters, the tests in the parameterizedTests
> package are making use of new junit 4.1 features for providing
> parameters to the tests and these tests don't currently fit into the
> simple junit 3.8 style and it will be much harder to re-use these tests
> from other frameworks in their current form. If we want to stick to the
> simple junit 3.8 style then these tests will need some refactoring.
>
> Regards,
>
> Andy.
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 19 April 2007 11:03
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
>
> In fact I'd say for the purposed of introspection by some other harness
> the old style is far preferable,  since it's easy to  examine the method
> names/signatures to determine what is a test and what is a setup method.
> I was about to start cleaning these up,  but I'd like to complete this
> discussion and decide whether we should be making everything use the old
> 3.8style or the new
> 4.1 annotations.  What I will do in the meantime is add setup methods to
> all the files in their existing style in order to fix up the issues with
> reusing type helpers between tests, and then revisit the style after the
> discussion has completed.  For simplicity I will use the same method
> signatures for setup methods as are used in 3.8 when using 4.1
> annotations.
>
> Regards, Kelvin.
>
>
> On 18/04/07, Andy Grove <gr...@roguewave.com> wrote:
> >
> >
> > Frank,
> >
> > You're absolutely right. I guess I'd forgotten that you could override
>
> > a protected method and make it public.
> >
> > In that case, it doesn't seem to matter if we use "old-style" junit or
>
> > annotations - it should still be possible to call the tests without
> > using the junit test runners.
> >
> > Andy.
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 17 April 2007 18:01
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes don't inherit from TestCase
> >
> > Hi Andy,
> >
> > Java allows you make something more visible in a derived class than in
>
> > the base, so declaring setUp() public in MyTest wouldn't seem to be a
> > problem.
> >
> >
> > Frank
> >
> > "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 12:19:37 PM:
> >
> > > Hi Frank,
> > >
> > > The TestCase class defines setUp and tearDown as protected methods,
> > > forcing the child class to also declare them as protected methods
> > > and this means they can't be loaded using reflection.
> > >
> > > Using junit 4.1 means we can declare the methods as public.
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > -----Original Message-----
> > > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > > Sent: 17 April 2007 17:03
> > > To: tuscany-dev@ws.apache.org
> > > Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
>
> > > classes don't inherit from TestCase
> > >
> > > Hi Andy,
> > >
> > > Maybe this is a stupid question (my junit ignorance showing through
> > :-),
> > > but couldn't you have run your simple test harness (main) even if
> > MyTest
> > > extended from TestCase? Is there something about having the base
> > > class that prevents you from simply invoking the test methods
> directly?
> > >
> > > Frank.
> > >
> > > "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:
> > >
> > > >
> > > > To better understand this myself, I just put a simple test case
> > > > together using junit 4.1 with annotations and made use of the
> > > > junit assertion calls e.g.
> > > >
> > > > public class MyTest {
> > > >     @Test
> > > >     public void testSomething() {
> > > >         // this test will fail
> > > >         assertEquals( "numbers are same", 1, 2 );
> > > >     }
> > > > }
> > > >
> > > > I then wrote a simple test harness to load the test class using
> > > > reflection and invoke any methods starting with "test".
> > > >
> > > >  public static void main(String[] args) throws Exception {
> > > >         Class testClass = Class.forName( "test.MyTest" );
> > > >         Object testObject = testClass.newInstance();
> > > >         Method method[] = testClass.getMethods();
> > > >         for (int i = 0; i < method.length; i++) {
> > > >             if (method[i].getName().startsWith("test")) {
> > > >                 System.out.println("Running " +
> > method[i].getName());
> > > >                 try {
> > > >                     method[i].invoke( testObject );
> > > >                 } catch (Throwable th) {
> > > >                     th.printStackTrace();
> > > >                 }
> > > >             }
> > > >         }
> > > >     }
> > > >
> > > > This ran the above test method and caught the following exception:
> > > >
> > > > java.lang.AssertionError: numbers are same expected:<1> but
> > > > was:<2>
> > > >
> > > > For me, this seems to demonstrate that using junit 4.1 style tests
>
> > > > will allow people to call their tests from their own test
> > > > harnesses without requiring junit-users to have to go to any
> special effort.
> > The
> > >
> > > > junit
> > > > Assert.* methods simply check some criteria and then call fail()
> > > > if that criteria is false. The fail() method simply throws an
> > > AssertionError.
> > > >
> > > > Writing the CTS tests using junit with annotations (rather than
> > > > extending TestCase) does seem to provide everything required to
> > allow
> > > > users to run the tests outside of junit, albeit with a dependency
> > > > on
> >
> > > > junit.jar but I don't see why that would be a problem for anyone?
> > > > We
> >
> > > > could write our own versions of the assert* methods but they would
> > do
> > > > exactly the same thing as the junit implementation so this seems
> > > > rather pointless.
> > > >
> > > > My conclusion is that we should continue writing SDO CTS tests
> > > > using
> >
> > > > junit, but ensure we use the annotation pattern rather than
> > extending
> > > > TestCase. Is everyone happy with this?
> > > >
> > > > Thanks,
> > > >
> > > > Andy.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > > Sent: 17 April 2007 14:53
> > > > To: tuscany-dev@ws.apache.org
> > > > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp
> > > > when
> >
> > > > classes don't inherit from TestCase
> > > >
> > > > Yes, I was about to write to the list on this subject. I'd like to
>
> > > > understand more of how the test harness agnosticism was intended,
> > and
> > > > whether its really practical. As it stands there is still junit
> > > > through and through,  in particular, each test method still
> > references
> > >
> > > > junit assertion calls.  Even if we could do assertions from
> > > > annotations (as per JML pre and post conditions),  we still have
> > > > all
> > > the junit imports.
> > > > If that were possible, then I guess each of the test methods could
> > be
> > > > invoked by something other than the junit test harness,  but they
> > > > would have trouble asserting anything about the success of the
> > method
> > > > invocation,  since there are no artifacts available before or
> > > > after the method invocation to make assertions about.
> > > >
> > > > Kelvin
> > > >
> > > > On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> > > > >
> > > > > If the goal is to make the tests "harness agnostic", then I
> > > > > don't see much difference between a JUnit-specific inheritance
> > dependency
> > > > > and a JUnit-specific annotation dependency.  Is the annotation
> > > > > dependency less troublesome for some reason?
> > > > >
> > > > >    Simon
> > > > >
> > > > > kelvin goodson wrote:
> > > > >
> > > > > > Thanks for this Andy,  I'll play with it tomorrow.
> > > > > >
> > > > > > Regards, Kelvin.
> > > > > >
> > > > > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >> I believe you just need to annotate the setUp method with
> > > @Before.
> > > > > >> This is described in the junit cookbook, here:
> > > > > >>
> > > > > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > > > > >>
> > > > > >> I'm currently working on submitting some more XSD test cases
> > > > > >> in
> >
> > > > > >> the
> > > >
> > > > > >> CTS so I'll try this method out. Hopefully I can then remove
> > the
> > > > > >> current dependency on TestCase in those tests.
> > > > > >>
> > > > > >> Thanks,
> > > > > >>
> > > > > >> Andy.
> > > > > >>
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: kelvingoodson@gmail.com
> > > > > >> [mailto:kelvingoodson@gmail.com]
> > On
> > > > > Behalf
> > > > > >> Of kelvin goodson
> > > > > >> Sent: 16 April 2007 14:42
> > > > > >> To: tuscany-dev@ws.apache.org
> > > > > >> Cc: Robbie Minshall
> > > > > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp
> > when
> > > > > classes
> > > > > >> don't inherit from TestCase
> > > > > >>
> > > > > >> Hi,
> > > > > >> I'm looking at doing some work in the CTS. I was looking back
> > at
> > > > > >> Robbie's attached description about how to keep the tests
> > > > > >> "harness agnostic".  I'm assuming that this is still a goal
> > > > > >> of the CTS although
> > > > > I
> > > > > >> may have missed something in my catching up. In my quest to
> > make
> > > > > >> the
> > > > > CTS
> > > > > >> better I note that a number of the test case classes still
> > extend
> > >
> > > > > >> the junit TestCase class.
> > > > > >> This is true for all test classes that have a setUp() method.
> > One
> > >
> > > > > >> that doesn't inherit from TestCase is XSDSerializationTest,
> > and
> > > > > >> adding a setUp method to this class doesn't cause junit to
> > invoke
> > >
> > > > > >> it in my eclipse environment. I'm trying to work out whether
> > > > > >> I should I expect a 4.1environment to discover and execute
> > > > > >> the setUp method when junit is used in this way. I seem to
> > > > > >> have Eclipse junit
> > > >
> > > > > >> plugins for 3.8.1 and
> > > > > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to
> > > > > >> offer
> >
> > > > > >> much in the way of configuration, so I can't be sure I'm
> > > > > >> using
> > > > > >> 4.1
> > > > behaviour.
> > > > > >>
> > > > > >> I really would like to be XSDSerializationTests to execute
> > setUp
> > > > > >> so
> > > > > that
> > > > > >> we can have a fresh HelperContext per test,  and I guess the
> > easy
> > >
> > > > > >> way out is to make the test class inherit from TestCase like
> > the
> > > > > >> others, but I'd prefer not to introduce the explicit
> > > > > >> dependency
> >
> > > > > >> on Junit if I can avoid it.
> > > > > >>
> > > > > >> Regards Kelvin.
> > > > > >>
> > > > > >>
> > > > > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > > > > >> >
> > > > > >> > This sounds quite good.
> > > > > >> >
> > > > > >> > I have written some test cases with Brian Murray which I
> > would
> > > > > >> > be
> > > >
> > > > > >> > happy to contribute to tuscany.  Identifying duplication
> > > > > >> > and differences in similar tests would probably be an
> > > > > >> > intersting
> > > > > excercise
> > > > > >> right off the bat.
> > > > > >> >
> > > > > >> > One decision that we spent a little time mulling over was
> > > > > >> > the
> >
> > > > > >> > framework to use for our test suite.  Originally we used
> > > > > >> > the much
> > > >
> > > > > >> > loved junit harness which worked well.  Different runtimes
> > > > > >> > ( command line, J2EE Application Server, a Service
> > > > > >> > Container ) have
> > > >
> > > > > >> > different
> > > > > >> classloader hierarchies etc.
> > > > > >> > Without many modifications to the junit code it was
> > > > > >> > difficult
> >
> > > > > >> > and
> > > >
> > > > > >> > quite ugly testing SDO within the context of a variety of
> > > > > >> > runtimes which the SDO APIs will be used.
> > > > > >> >
> > > > > >> > We took the approach of writing general test libraries
> > > > > >> > which can then simply be called from a variety of test
> > > > > >> > frameworks such as junit or a simple J2EE or SCA
> > > > > >> > Application test
> > harness.
> > >
> > > > > >> > I like this approach
> > > > > for
> > > > > >>
> > > > > >> > keeping the actual test code very simple, allowing for
> > > > > >> > integration a variety of test frameworks, and providing
> > ability
> > >
> > > > > >> > to test directly within the different runtimes people care
> > > about.
> > > > > >> >
> > > > > >> > Any thoughts on this ?
> > > > > >> >
> > > > > >> > Robbie
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com >
> wrote:
> > > > > >> > >
> > > > > >> > > Andy,
> > > > > >> > >   please attach them to the JIRA for this work and one of
> > us
> > > > > >> > > can pick them up, thanks.
> > > > > >> > > Best Regards, Kelvin.
> > > > > >> > >
> > > > > >> > > On 01/12/06, Andy Grove (Contractor)
> > > > > >> > > <gr...@roguewave.com>
> > > > wrote:
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > Hi Dan,
> > > > > >> > > >
> > > > > >> > > > I was previously working with Kelvin Goodson to donate
> > some
> > >
> > > > > >> > > > junit
> > > > > >> > > tests
> > > > > >> > > > on behalf of Rogue Wave Software.
> > > > > >> > > >
> > > > > >> > > > These tests are written purely to the SDO API and I
> > > > > >> > > > have
> > > > > validated
> > > > > >> > > that
> > > > > >> > > > the tests do run against Tuscany as well as Rogue
> > > > > >> > > > Wave's
> > > > > >> > > implementation.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > Should I send the tests to Kelvin?
> > > > > >> > > >
> > > > > >> > > > Thanks,
> > > > > >> > > >
> > > > > >> > > > Andy.
> > > > > >> > > >
> > > > > >> > > > -----Original Message-----
> > > > > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > > > >> > > > Sent: 30 November 2006 17:44
> > > > > >> > > > To: Tuscany Developers; Tuscany Users
> > > > > >> > > > Subject: Proposal for a (Java) community test suite for
> > SDO
> > > > > >> > > >
> > > > > >> > > > 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
> > > > > >> > > >
> > > > > >> > > >
> > > > > ----------------------------------------------------------------
> > > > > --
> > > > > >> > > > --- To unsubscribe, e-mail:
> > > > > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > > >> > > > For additional commands, e-mail:
> > > > > >> > > > tuscany-dev-help@ws.apache.org
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > * * * 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
> > > > > >>
> > > > > >>
> > -----------------------------------------------------------------
> > > > > >> --
> > > > > >> -- To unsubscribe, e-mail:
> > tuscany-dev-unsubscribe@ws.apache.org
> > > > > >> For additional commands, e-mail:
> > > > > >> tuscany-dev-help@ws.apache.org
> > > > > >>
> > > > > >>
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > --------------------------------------------------------------------
> > > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

Just for clarification, I think we're saying that the important thing
here is the method naming convention, rather than requiring the tests to
extend TestCase?

If we follow the junit 3.8 naming convention and always use the method
names setUp / teardown (and make sure they are public methods) and have
all test methods start with "test" then it won't matter if the tests
extend TestCase or have junit 4.1 annotations.

However, just to complicate matters, the tests in the parameterizedTests
package are making use of new junit 4.1 features for providing
parameters to the tests and these tests don't currently fit into the
simple junit 3.8 style and it will be much harder to re-use these tests
from other frameworks in their current form. If we want to stick to the
simple junit 3.8 style then these tests will need some refactoring. 

Regards,

Andy.

-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com] 
Sent: 19 April 2007 11:03
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

In fact I'd say for the purposed of introspection by some other harness
the old style is far preferable,  since it's easy to  examine the method
names/signatures to determine what is a test and what is a setup method.
I was about to start cleaning these up,  but I'd like to complete this
discussion and decide whether we should be making everything use the old
3.8style or the new
4.1 annotations.  What I will do in the meantime is add setup methods to
all the files in their existing style in order to fix up the issues with
reusing type helpers between tests, and then revisit the style after the
discussion has completed.  For simplicity I will use the same method
signatures for setup methods as are used in 3.8 when using 4.1
annotations.

Regards, Kelvin.


On 18/04/07, Andy Grove <gr...@roguewave.com> wrote:
>
>
> Frank,
>
> You're absolutely right. I guess I'd forgotten that you could override

> a protected method and make it public.
>
> In that case, it doesn't seem to matter if we use "old-style" junit or

> annotations - it should still be possible to call the tests without 
> using the junit test runners.
>
> Andy.
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 17 April 2007 18:01
> To: tuscany-dev@ws.apache.org
> Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
> classes don't inherit from TestCase
>
> Hi Andy,
>
> Java allows you make something more visible in a derived class than in

> the base, so declaring setUp() public in MyTest wouldn't seem to be a 
> problem.
>
>
> Frank
>
> "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 12:19:37 PM:
>
> > Hi Frank,
> >
> > The TestCase class defines setUp and tearDown as protected methods, 
> > forcing the child class to also declare them as protected methods 
> > and this means they can't be loaded using reflection.
> >
> > Using junit 4.1 means we can declare the methods as public.
> >
> > Thanks,
> >
> > Andy.
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 17 April 2007 17:03
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when

> > classes don't inherit from TestCase
> >
> > Hi Andy,
> >
> > Maybe this is a stupid question (my junit ignorance showing through
> :-),
> > but couldn't you have run your simple test harness (main) even if
> MyTest
> > extended from TestCase? Is there something about having the base 
> > class that prevents you from simply invoking the test methods
directly?
> >
> > Frank.
> >
> > "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:
> >
> > >
> > > To better understand this myself, I just put a simple test case 
> > > together using junit 4.1 with annotations and made use of the 
> > > junit assertion calls e.g.
> > >
> > > public class MyTest {
> > >     @Test
> > >     public void testSomething() {
> > >         // this test will fail
> > >         assertEquals( "numbers are same", 1, 2 );
> > >     }
> > > }
> > >
> > > I then wrote a simple test harness to load the test class using 
> > > reflection and invoke any methods starting with "test".
> > >
> > >  public static void main(String[] args) throws Exception {
> > >         Class testClass = Class.forName( "test.MyTest" );
> > >         Object testObject = testClass.newInstance();
> > >         Method method[] = testClass.getMethods();
> > >         for (int i = 0; i < method.length; i++) {
> > >             if (method[i].getName().startsWith("test")) {
> > >                 System.out.println("Running " +
> method[i].getName());
> > >                 try {
> > >                     method[i].invoke( testObject );
> > >                 } catch (Throwable th) {
> > >                     th.printStackTrace();
> > >                 }
> > >             }
> > >         }
> > >     }
> > >
> > > This ran the above test method and caught the following exception:
> > >
> > > java.lang.AssertionError: numbers are same expected:<1> but 
> > > was:<2>
> > >
> > > For me, this seems to demonstrate that using junit 4.1 style tests

> > > will allow people to call their tests from their own test 
> > > harnesses without requiring junit-users to have to go to any
special effort.
> The
> >
> > > junit
> > > Assert.* methods simply check some criteria and then call fail() 
> > > if that criteria is false. The fail() method simply throws an
> > AssertionError.
> > >
> > > Writing the CTS tests using junit with annotations (rather than 
> > > extending TestCase) does seem to provide everything required to
> allow
> > > users to run the tests outside of junit, albeit with a dependency 
> > > on
>
> > > junit.jar but I don't see why that would be a problem for anyone? 
> > > We
>
> > > could write our own versions of the assert* methods but they would
> do
> > > exactly the same thing as the junit implementation so this seems 
> > > rather pointless.
> > >
> > > My conclusion is that we should continue writing SDO CTS tests 
> > > using
>
> > > junit, but ensure we use the annotation pattern rather than
> extending
> > > TestCase. Is everyone happy with this?
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 17 April 2007 14:53
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp 
> > > when
>
> > > classes don't inherit from TestCase
> > >
> > > Yes, I was about to write to the list on this subject. I'd like to

> > > understand more of how the test harness agnosticism was intended,
> and
> > > whether its really practical. As it stands there is still junit 
> > > through and through,  in particular, each test method still
> references
> >
> > > junit assertion calls.  Even if we could do assertions from 
> > > annotations (as per JML pre and post conditions),  we still have 
> > > all
> > the junit imports.
> > > If that were possible, then I guess each of the test methods could
> be
> > > invoked by something other than the junit test harness,  but they 
> > > would have trouble asserting anything about the success of the
> method
> > > invocation,  since there are no artifacts available before or 
> > > after the method invocation to make assertions about.
> > >
> > > Kelvin
> > >
> > > On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> > > >
> > > > If the goal is to make the tests "harness agnostic", then I 
> > > > don't see much difference between a JUnit-specific inheritance
> dependency
> > > > and a JUnit-specific annotation dependency.  Is the annotation 
> > > > dependency less troublesome for some reason?
> > > >
> > > >    Simon
> > > >
> > > > kelvin goodson wrote:
> > > >
> > > > > Thanks for this Andy,  I'll play with it tomorrow.
> > > > >
> > > > > Regards, Kelvin.
> > > > >
> > > > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> I believe you just need to annotate the setUp method with
> > @Before.
> > > > >> This is described in the junit cookbook, here:
> > > > >>
> > > > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > > > >>
> > > > >> I'm currently working on submitting some more XSD test cases 
> > > > >> in
>
> > > > >> the
> > >
> > > > >> CTS so I'll try this method out. Hopefully I can then remove
> the
> > > > >> current dependency on TestCase in those tests.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Andy.
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: kelvingoodson@gmail.com 
> > > > >> [mailto:kelvingoodson@gmail.com]
> On
> > > > Behalf
> > > > >> Of kelvin goodson
> > > > >> Sent: 16 April 2007 14:42
> > > > >> To: tuscany-dev@ws.apache.org
> > > > >> Cc: Robbie Minshall
> > > > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp
> when
> > > > classes
> > > > >> don't inherit from TestCase
> > > > >>
> > > > >> Hi,
> > > > >> I'm looking at doing some work in the CTS. I was looking back
> at
> > > > >> Robbie's attached description about how to keep the tests 
> > > > >> "harness agnostic".  I'm assuming that this is still a goal 
> > > > >> of the CTS although
> > > > I
> > > > >> may have missed something in my catching up. In my quest to
> make
> > > > >> the
> > > > CTS
> > > > >> better I note that a number of the test case classes still
> extend
> >
> > > > >> the junit TestCase class.
> > > > >> This is true for all test classes that have a setUp() method.
> One
> >
> > > > >> that doesn't inherit from TestCase is XSDSerializationTest,
> and
> > > > >> adding a setUp method to this class doesn't cause junit to
> invoke
> >
> > > > >> it in my eclipse environment. I'm trying to work out whether 
> > > > >> I should I expect a 4.1environment to discover and execute 
> > > > >> the setUp method when junit is used in this way. I seem to 
> > > > >> have Eclipse junit
> > >
> > > > >> plugins for 3.8.1 and
> > > > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to 
> > > > >> offer
>
> > > > >> much in the way of configuration, so I can't be sure I'm 
> > > > >> using
> > > > >> 4.1
> > > behaviour.
> > > > >>
> > > > >> I really would like to be XSDSerializationTests to execute
> setUp
> > > > >> so
> > > > that
> > > > >> we can have a fresh HelperContext per test,  and I guess the
> easy
> >
> > > > >> way out is to make the test class inherit from TestCase like
> the
> > > > >> others, but I'd prefer not to introduce the explicit 
> > > > >> dependency
>
> > > > >> on Junit if I can avoid it.
> > > > >>
> > > > >> Regards Kelvin.
> > > > >>
> > > > >>
> > > > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > > > >> >
> > > > >> > This sounds quite good.
> > > > >> >
> > > > >> > I have written some test cases with Brian Murray which I
> would
> > > > >> > be
> > >
> > > > >> > happy to contribute to tuscany.  Identifying duplication 
> > > > >> > and differences in similar tests would probably be an 
> > > > >> > intersting
> > > > excercise
> > > > >> right off the bat.
> > > > >> >
> > > > >> > One decision that we spent a little time mulling over was 
> > > > >> > the
>
> > > > >> > framework to use for our test suite.  Originally we used 
> > > > >> > the much
> > >
> > > > >> > loved junit harness which worked well.  Different runtimes 
> > > > >> > ( command line, J2EE Application Server, a Service 
> > > > >> > Container ) have
> > >
> > > > >> > different
> > > > >> classloader hierarchies etc.
> > > > >> > Without many modifications to the junit code it was 
> > > > >> > difficult
>
> > > > >> > and
> > >
> > > > >> > quite ugly testing SDO within the context of a variety of 
> > > > >> > runtimes which the SDO APIs will be used.
> > > > >> >
> > > > >> > We took the approach of writing general test libraries 
> > > > >> > which can then simply be called from a variety of test 
> > > > >> > frameworks such as junit or a simple J2EE or SCA 
> > > > >> > Application test
> harness.
> >
> > > > >> > I like this approach
> > > > for
> > > > >>
> > > > >> > keeping the actual test code very simple, allowing for 
> > > > >> > integration a variety of test frameworks, and providing
> ability
> >
> > > > >> > to test directly within the different runtimes people care
> > about.
> > > > >> >
> > > > >> > Any thoughts on this ?
> > > > >> >
> > > > >> > Robbie
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com >
wrote:
> > > > >> > >
> > > > >> > > Andy,
> > > > >> > >   please attach them to the JIRA for this work and one of
> us
> > > > >> > > can pick them up, thanks.
> > > > >> > > Best Regards, Kelvin.
> > > > >> > >
> > > > >> > > On 01/12/06, Andy Grove (Contractor) 
> > > > >> > > <gr...@roguewave.com>
> > > wrote:
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Hi Dan,
> > > > >> > > >
> > > > >> > > > I was previously working with Kelvin Goodson to donate
> some
> >
> > > > >> > > > junit
> > > > >> > > tests
> > > > >> > > > on behalf of Rogue Wave Software.
> > > > >> > > >
> > > > >> > > > These tests are written purely to the SDO API and I 
> > > > >> > > > have
> > > > validated
> > > > >> > > that
> > > > >> > > > the tests do run against Tuscany as well as Rogue 
> > > > >> > > > Wave's
> > > > >> > > implementation.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Should I send the tests to Kelvin?
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > >
> > > > >> > > > Andy.
> > > > >> > > >
> > > > >> > > > -----Original Message-----
> > > > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > > >> > > > Sent: 30 November 2006 17:44
> > > > >> > > > To: Tuscany Developers; Tuscany Users
> > > > >> > > > Subject: Proposal for a (Java) community test suite for
> SDO
> > > > >> > > >
> > > > >> > > > 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
> > > > >> > > >
> > > > >> > > >
> > > > ----------------------------------------------------------------
> > > > --
> > > > >> > > > --- To unsubscribe, e-mail:
> > > > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > >> > > > For additional commands, e-mail:
> > > > >> > > > tuscany-dev-help@ws.apache.org
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > * * * 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
> > > > >>
> > > > >>
> -----------------------------------------------------------------
> > > > >> --
> > > > >> -- To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> > > > >> For additional commands, e-mail: 
> > > > >> tuscany-dev-help@ws.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > >
> --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@gmail.com>.

In fact I'd say for the purposed of introspection by some other harness the
old style is far preferable,  since it's easy to  examine the method
names/signatures to determine what is a test and what is a setup method.  I
was about to start cleaning these up,  but I'd like to complete this
discussion and decide whether we should be making everything use the
old 3.8style or the new
4.1 annotations.  What I will do in the meantime is add setup methods to all
the files in their existing style in order to fix up the issues with reusing
type helpers between tests, and then revisit the style after the discussion
has completed.  For simplicity I will use the same method signatures for
setup methods as are used in 3.8 when using 4.1 annotations.

Regards, Kelvin.


On 18/04/07, Andy Grove <gr...@roguewave.com> wrote:
>
>
> Frank,
>
> You're absolutely right. I guess I'd forgotten that you could override a
> protected method and make it public.
>
> In that case, it doesn't seem to matter if we use "old-style" junit or
> annotations - it should still be possible to call the tests without
> using the junit test runners.
>
> Andy.
>
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> Sent: 17 April 2007 18:01
> To: tuscany-dev@ws.apache.org
> Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
>
> Hi Andy,
>
> Java allows you make something more visible in a derived class than in
> the base, so declaring setUp() public in MyTest wouldn't seem to be a
> problem.
>
>
> Frank
>
> "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 12:19:37 PM:
>
> > Hi Frank,
> >
> > The TestCase class defines setUp and tearDown as protected methods,
> > forcing the child class to also declare them as protected methods and
> > this means they can't be loaded using reflection.
> >
> > Using junit 4.1 means we can declare the methods as public.
> >
> > Thanks,
> >
> > Andy.
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:frankb@ca.ibm.com]
> > Sent: 17 April 2007 17:03
> > To: tuscany-dev@ws.apache.org
> > Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes don't inherit from TestCase
> >
> > Hi Andy,
> >
> > Maybe this is a stupid question (my junit ignorance showing through
> :-),
> > but couldn't you have run your simple test harness (main) even if
> MyTest
> > extended from TestCase? Is there something about having the base class
> > that prevents you from simply invoking the test methods directly?
> >
> > Frank.
> >
> > "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:
> >
> > >
> > > To better understand this myself, I just put a simple test case
> > > together using junit 4.1 with annotations and made use of the junit
> > > assertion calls e.g.
> > >
> > > public class MyTest {
> > >     @Test
> > >     public void testSomething() {
> > >         // this test will fail
> > >         assertEquals( "numbers are same", 1, 2 );
> > >     }
> > > }
> > >
> > > I then wrote a simple test harness to load the test class using
> > > reflection and invoke any methods starting with "test".
> > >
> > >  public static void main(String[] args) throws Exception {
> > >         Class testClass = Class.forName( "test.MyTest" );
> > >         Object testObject = testClass.newInstance();
> > >         Method method[] = testClass.getMethods();
> > >         for (int i = 0; i < method.length; i++) {
> > >             if (method[i].getName().startsWith("test")) {
> > >                 System.out.println("Running " +
> method[i].getName());
> > >                 try {
> > >                     method[i].invoke( testObject );
> > >                 } catch (Throwable th) {
> > >                     th.printStackTrace();
> > >                 }
> > >             }
> > >         }
> > >     }
> > >
> > > This ran the above test method and caught the following exception:
> > >
> > > java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> > >
> > > For me, this seems to demonstrate that using junit 4.1 style tests
> > > will allow people to call their tests from their own test harnesses
> > > without requiring junit-users to have to go to any special effort.
> The
> >
> > > junit
> > > Assert.* methods simply check some criteria and then call fail() if
> > > that criteria is false. The fail() method simply throws an
> > AssertionError.
> > >
> > > Writing the CTS tests using junit with annotations (rather than
> > > extending TestCase) does seem to provide everything required to
> allow
> > > users to run the tests outside of junit, albeit with a dependency on
>
> > > junit.jar but I don't see why that would be a problem for anyone? We
>
> > > could write our own versions of the assert* methods but they would
> do
> > > exactly the same thing as the junit implementation so this seems
> > > rather pointless.
> > >
> > > My conclusion is that we should continue writing SDO CTS tests using
>
> > > junit, but ensure we use the annotation pattern rather than
> extending
> > > TestCase. Is everyone happy with this?
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > > Sent: 17 April 2007 14:53
> > > To: tuscany-dev@ws.apache.org
> > > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
>
> > > classes don't inherit from TestCase
> > >
> > > Yes, I was about to write to the list on this subject. I'd like to
> > > understand more of how the test harness agnosticism was intended,
> and
> > > whether its really practical. As it stands there is still junit
> > > through and through,  in particular, each test method still
> references
> >
> > > junit assertion calls.  Even if we could do assertions from
> > > annotations (as per JML pre and post conditions),  we still have all
> > the junit imports.
> > > If that were possible, then I guess each of the test methods could
> be
> > > invoked by something other than the junit test harness,  but they
> > > would have trouble asserting anything about the success of the
> method
> > > invocation,  since there are no artifacts available before or after
> > > the method invocation to make assertions about.
> > >
> > > Kelvin
> > >
> > > On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> > > >
> > > > If the goal is to make the tests "harness agnostic", then I don't
> > > > see much difference between a JUnit-specific inheritance
> dependency
> > > > and a JUnit-specific annotation dependency.  Is the annotation
> > > > dependency less troublesome for some reason?
> > > >
> > > >    Simon
> > > >
> > > > kelvin goodson wrote:
> > > >
> > > > > Thanks for this Andy,  I'll play with it tomorrow.
> > > > >
> > > > > Regards, Kelvin.
> > > > >
> > > > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> I believe you just need to annotate the setUp method with
> > @Before.
> > > > >> This is described in the junit cookbook, here:
> > > > >>
> > > > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > > > >>
> > > > >> I'm currently working on submitting some more XSD test cases in
>
> > > > >> the
> > >
> > > > >> CTS so I'll try this method out. Hopefully I can then remove
> the
> > > > >> current dependency on TestCase in those tests.
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> Andy.
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com]
> On
> > > > Behalf
> > > > >> Of kelvin goodson
> > > > >> Sent: 16 April 2007 14:42
> > > > >> To: tuscany-dev@ws.apache.org
> > > > >> Cc: Robbie Minshall
> > > > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp
> when
> > > > classes
> > > > >> don't inherit from TestCase
> > > > >>
> > > > >> Hi,
> > > > >> I'm looking at doing some work in the CTS. I was looking back
> at
> > > > >> Robbie's attached description about how to keep the tests
> > > > >> "harness agnostic".  I'm assuming that this is still a goal of
> > > > >> the CTS although
> > > > I
> > > > >> may have missed something in my catching up. In my quest to
> make
> > > > >> the
> > > > CTS
> > > > >> better I note that a number of the test case classes still
> extend
> >
> > > > >> the junit TestCase class.
> > > > >> This is true for all test classes that have a setUp() method.
> One
> >
> > > > >> that doesn't inherit from TestCase is XSDSerializationTest,
> and
> > > > >> adding a setUp method to this class doesn't cause junit to
> invoke
> >
> > > > >> it in my eclipse environment. I'm trying to work out whether I
> > > > >> should I expect a 4.1environment to discover and execute the
> > > > >> setUp method when junit is used in this way. I seem to have
> > > > >> Eclipse junit
> > >
> > > > >> plugins for 3.8.1 and
> > > > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer
>
> > > > >> much in the way of configuration, so I can't be sure I'm using
> > > > >> 4.1
> > > behaviour.
> > > > >>
> > > > >> I really would like to be XSDSerializationTests to execute
> setUp
> > > > >> so
> > > > that
> > > > >> we can have a fresh HelperContext per test,  and I guess the
> easy
> >
> > > > >> way out is to make the test class inherit from TestCase like
> the
> > > > >> others, but I'd prefer not to introduce the explicit dependency
>
> > > > >> on Junit if I can avoid it.
> > > > >>
> > > > >> Regards Kelvin.
> > > > >>
> > > > >>
> > > > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > > > >> >
> > > > >> > This sounds quite good.
> > > > >> >
> > > > >> > I have written some test cases with Brian Murray which I
> would
> > > > >> > be
> > >
> > > > >> > happy to contribute to tuscany.  Identifying duplication and
> > > > >> > differences in similar tests would probably be an intersting
> > > > excercise
> > > > >> right off the bat.
> > > > >> >
> > > > >> > One decision that we spent a little time mulling over was the
>
> > > > >> > framework to use for our test suite.  Originally we used the
> > > > >> > much
> > >
> > > > >> > loved junit harness which worked well.  Different runtimes (
> > > > >> > command line, J2EE Application Server, a Service Container )
> > > > >> > have
> > >
> > > > >> > different
> > > > >> classloader hierarchies etc.
> > > > >> > Without many modifications to the junit code it was difficult
>
> > > > >> > and
> > >
> > > > >> > quite ugly testing SDO within the context of a variety of
> > > > >> > runtimes which the SDO APIs will be used.
> > > > >> >
> > > > >> > We took the approach of writing general test libraries which
> > > > >> > can then simply be called from a variety of test frameworks
> > > > >> > such as junit or a simple J2EE or SCA Application test
> harness.
> >
> > > > >> > I like this approach
> > > > for
> > > > >>
> > > > >> > keeping the actual test code very simple, allowing for
> > > > >> > integration a variety of test frameworks, and providing
> ability
> >
> > > > >> > to test directly within the different runtimes people care
> > about.
> > > > >> >
> > > > >> > Any thoughts on this ?
> > > > >> >
> > > > >> > Robbie
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > > > >> > >
> > > > >> > > Andy,
> > > > >> > >   please attach them to the JIRA for this work and one of
> us
> > > > >> > > can pick them up, thanks.
> > > > >> > > Best Regards, Kelvin.
> > > > >> > >
> > > > >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
> > > wrote:
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Hi Dan,
> > > > >> > > >
> > > > >> > > > I was previously working with Kelvin Goodson to donate
> some
> >
> > > > >> > > > junit
> > > > >> > > tests
> > > > >> > > > on behalf of Rogue Wave Software.
> > > > >> > > >
> > > > >> > > > These tests are written purely to the SDO API and I have
> > > > validated
> > > > >> > > that
> > > > >> > > > the tests do run against Tuscany as well as Rogue Wave's
> > > > >> > > implementation.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Should I send the tests to Kelvin?
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > >
> > > > >> > > > Andy.
> > > > >> > > >
> > > > >> > > > -----Original Message-----
> > > > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > > >> > > > Sent: 30 November 2006 17:44
> > > > >> > > > To: Tuscany Developers; Tuscany Users
> > > > >> > > > Subject: Proposal for a (Java) community test suite for
> SDO
> > > > >> > > >
> > > > >> > > > 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
> > > > >> > > >
> > > > >> > > >
> > > > ------------------------------------------------------------------
> > > > >> > > > --- To unsubscribe, e-mail:
> > > > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > > >> > > > For additional commands, e-mail:
> > > > >> > > > tuscany-dev-help@ws.apache.org
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > * * * 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
> > > > >>
> > > > >>
> -----------------------------------------------------------------
> > > > >> --
> > > > >> -- To unsubscribe, e-mail:
> tuscany-dev-unsubscribe@ws.apache.org
> > > > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > >
> --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

Frank,

You're absolutely right. I guess I'd forgotten that you could override a
protected method and make it public.

In that case, it doesn't seem to matter if we use "old-style" junit or
annotations - it should still be possible to call the tests without
using the junit test runners.

Andy.

-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Sent: 17 April 2007 18:01
To: tuscany-dev@ws.apache.org
Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Hi Andy,

Java allows you make something more visible in a derived class than in
the base, so declaring setUp() public in MyTest wouldn't seem to be a
problem. 


Frank

"Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 12:19:37 PM:

> Hi Frank,
> 
> The TestCase class defines setUp and tearDown as protected methods,
> forcing the child class to also declare them as protected methods and
> this means they can't be loaded using reflection.
> 
> Using junit 4.1 means we can declare the methods as public.
> 
> Thanks,
> 
> Andy.
> 
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Sent: 17 April 2007 17:03
> To: tuscany-dev@ws.apache.org
> Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
> 
> Hi Andy,
> 
> Maybe this is a stupid question (my junit ignorance showing through
:-),
> but couldn't you have run your simple test harness (main) even if
MyTest
> extended from TestCase? Is there something about having the base class
> that prevents you from simply invoking the test methods directly?
> 
> Frank.
> 
> "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:
> 
> > 
> > To better understand this myself, I just put a simple test case 
> > together using junit 4.1 with annotations and made use of the junit 
> > assertion calls e.g.
> > 
> > public class MyTest {
> >     @Test
> >     public void testSomething() {
> >         // this test will fail
> >         assertEquals( "numbers are same", 1, 2 );
> >     }
> > }
> > 
> > I then wrote a simple test harness to load the test class using 
> > reflection and invoke any methods starting with "test".
> > 
> >  public static void main(String[] args) throws Exception {
> >         Class testClass = Class.forName( "test.MyTest" );
> >         Object testObject = testClass.newInstance();
> >         Method method[] = testClass.getMethods();
> >         for (int i = 0; i < method.length; i++) {
> >             if (method[i].getName().startsWith("test")) {
> >                 System.out.println("Running " +
method[i].getName());
> >                 try {
> >                     method[i].invoke( testObject );
> >                 } catch (Throwable th) {
> >                     th.printStackTrace();
> >                 }
> >             }
> >         }
> >     }
> > 
> > This ran the above test method and caught the following exception:
> > 
> > java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> > 
> > For me, this seems to demonstrate that using junit 4.1 style tests 
> > will allow people to call their tests from their own test harnesses 
> > without requiring junit-users to have to go to any special effort.
The
> 
> > junit
> > Assert.* methods simply check some criteria and then call fail() if 
> > that criteria is false. The fail() method simply throws an
> AssertionError.
> > 
> > Writing the CTS tests using junit with annotations (rather than 
> > extending TestCase) does seem to provide everything required to
allow 
> > users to run the tests outside of junit, albeit with a dependency on

> > junit.jar but I don't see why that would be a problem for anyone? We

> > could write our own versions of the assert* methods but they would
do 
> > exactly the same thing as the junit implementation so this seems 
> > rather pointless.
> > 
> > My conclusion is that we should continue writing SDO CTS tests using

> > junit, but ensure we use the annotation pattern rather than
extending 
> > TestCase. Is everyone happy with this?
> > 
> > Thanks,
> > 
> > Andy.
> > 
> > 
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 17 April 2007 14:53
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when

> > classes don't inherit from TestCase
> > 
> > Yes, I was about to write to the list on this subject. I'd like to 
> > understand more of how the test harness agnosticism was intended,
and 
> > whether its really practical. As it stands there is still junit 
> > through and through,  in particular, each test method still
references
> 
> > junit assertion calls.  Even if we could do assertions from 
> > annotations (as per JML pre and post conditions),  we still have all
> the junit imports.
> > If that were possible, then I guess each of the test methods could
be 
> > invoked by something other than the junit test harness,  but they 
> > would have trouble asserting anything about the success of the
method 
> > invocation,  since there are no artifacts available before or after 
> > the method invocation to make assertions about.
> > 
> > Kelvin
> > 
> > On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> > >
> > > If the goal is to make the tests "harness agnostic", then I don't 
> > > see much difference between a JUnit-specific inheritance
dependency 
> > > and a JUnit-specific annotation dependency.  Is the annotation 
> > > dependency less troublesome for some reason?
> > >
> > >    Simon
> > >
> > > kelvin goodson wrote:
> > >
> > > > Thanks for this Andy,  I'll play with it tomorrow.
> > > >
> > > > Regards, Kelvin.
> > > >
> > > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > > >
> > > >>
> > > >>
> > > >> I believe you just need to annotate the setUp method with
> @Before. 
> > > >> This is described in the junit cookbook, here:
> > > >>
> > > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > > >>
> > > >> I'm currently working on submitting some more XSD test cases in

> > > >> the
> > 
> > > >> CTS so I'll try this method out. Hopefully I can then remove
the 
> > > >> current dependency on TestCase in those tests.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Andy.
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com]
On
> > > Behalf
> > > >> Of kelvin goodson
> > > >> Sent: 16 April 2007 14:42
> > > >> To: tuscany-dev@ws.apache.org
> > > >> Cc: Robbie Minshall
> > > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp
when
> > > classes
> > > >> don't inherit from TestCase
> > > >>
> > > >> Hi,
> > > >> I'm looking at doing some work in the CTS. I was looking back
at 
> > > >> Robbie's attached description about how to keep the tests 
> > > >> "harness agnostic".  I'm assuming that this is still a goal of 
> > > >> the CTS although
> > > I
> > > >> may have missed something in my catching up. In my quest to
make 
> > > >> the
> > > CTS
> > > >> better I note that a number of the test case classes still
extend
> 
> > > >> the junit TestCase class.
> > > >> This is true for all test classes that have a setUp() method.
One
> 
> > > >> that doesn't inherit from TestCase is XSDSerializationTest,
and 
> > > >> adding a setUp method to this class doesn't cause junit to
invoke
> 
> > > >> it in my eclipse environment. I'm trying to work out whether I 
> > > >> should I expect a 4.1environment to discover and execute the 
> > > >> setUp method when junit is used in this way. I seem to have 
> > > >> Eclipse junit
> > 
> > > >> plugins for 3.8.1 and
> > > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer

> > > >> much in the way of configuration, so I can't be sure I'm using 
> > > >> 4.1
> > behaviour.
> > > >>
> > > >> I really would like to be XSDSerializationTests to execute
setUp 
> > > >> so
> > > that
> > > >> we can have a fresh HelperContext per test,  and I guess the
easy
> 
> > > >> way out is to make the test class inherit from TestCase like
the 
> > > >> others, but I'd prefer not to introduce the explicit dependency

> > > >> on Junit if I can avoid it.
> > > >>
> > > >> Regards Kelvin.
> > > >>
> > > >>
> > > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > > >> >
> > > >> > This sounds quite good.
> > > >> >
> > > >> > I have written some test cases with Brian Murray which I
would 
> > > >> > be
> > 
> > > >> > happy to contribute to tuscany.  Identifying duplication and 
> > > >> > differences in similar tests would probably be an intersting
> > > excercise
> > > >> right off the bat.
> > > >> >
> > > >> > One decision that we spent a little time mulling over was the

> > > >> > framework to use for our test suite.  Originally we used the 
> > > >> > much
> > 
> > > >> > loved junit harness which worked well.  Different runtimes ( 
> > > >> > command line, J2EE Application Server, a Service Container ) 
> > > >> > have
> > 
> > > >> > different
> > > >> classloader hierarchies etc.
> > > >> > Without many modifications to the junit code it was difficult

> > > >> > and
> > 
> > > >> > quite ugly testing SDO within the context of a variety of 
> > > >> > runtimes which the SDO APIs will be used.
> > > >> >
> > > >> > We took the approach of writing general test libraries which 
> > > >> > can then simply be called from a variety of test frameworks 
> > > >> > such as junit or a simple J2EE or SCA Application test
harness.
> 
> > > >> > I like this approach
> > > for
> > > >>
> > > >> > keeping the actual test code very simple, allowing for 
> > > >> > integration a variety of test frameworks, and providing
ability
> 
> > > >> > to test directly within the different runtimes people care
> about.
> > > >> >
> > > >> > Any thoughts on this ?
> > > >> >
> > > >> > Robbie
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > > >> > >
> > > >> > > Andy,
> > > >> > >   please attach them to the JIRA for this work and one of
us 
> > > >> > > can pick them up, thanks.
> > > >> > > Best Regards, Kelvin.
> > > >> > >
> > > >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
> > wrote:
> > > >> > > >
> > > >> > > >
> > > >> > > > Hi Dan,
> > > >> > > >
> > > >> > > > I was previously working with Kelvin Goodson to donate
some
> 
> > > >> > > > junit
> > > >> > > tests
> > > >> > > > on behalf of Rogue Wave Software.
> > > >> > > >
> > > >> > > > These tests are written purely to the SDO API and I have
> > > validated
> > > >> > > that
> > > >> > > > the tests do run against Tuscany as well as Rogue Wave's
> > > >> > > implementation.
> > > >> > > >
> > > >> > > >
> > > >> > > > Should I send the tests to Kelvin?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > >
> > > >> > > > Andy.
> > > >> > > >
> > > >> > > > -----Original Message-----
> > > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > >> > > > Sent: 30 November 2006 17:44
> > > >> > > > To: Tuscany Developers; Tuscany Users
> > > >> > > > Subject: Proposal for a (Java) community test suite for
SDO
> > > >> > > >
> > > >> > > > 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
> > > >> > > >
> > > >> > > >
> > > ------------------------------------------------------------------
> > > >> > > > --- To unsubscribe, e-mail: 
> > > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > >> > > > For additional commands, e-mail: 
> > > >> > > > tuscany-dev-help@ws.apache.org
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > * * * 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
> > > >>
> > > >>
-----------------------------------------------------------------
> > > >> --
> > > >> -- To unsubscribe, e-mail:
tuscany-dev-unsubscribe@ws.apache.org
> > > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> > >
--------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > 
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Frank Budinsky <fr...@ca.ibm.com>.

Hi Andy,

Java allows you make something more visible in a derived class than in the 
base, so declaring setUp() public in MyTest wouldn't seem to be a problem. 


Frank

"Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 12:19:37 PM:

> Hi Frank,
> 
> The TestCase class defines setUp and tearDown as protected methods,
> forcing the child class to also declare them as protected methods and
> this means they can't be loaded using reflection.
> 
> Using junit 4.1 means we can declare the methods as public.
> 
> Thanks,
> 
> Andy.
> 
> -----Original Message-----
> From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
> Sent: 17 April 2007 17:03
> To: tuscany-dev@ws.apache.org
> Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
> 
> Hi Andy,
> 
> Maybe this is a stupid question (my junit ignorance showing through :-),
> but couldn't you have run your simple test harness (main) even if MyTest
> extended from TestCase? Is there something about having the base class
> that prevents you from simply invoking the test methods directly?
> 
> Frank.
> 
> "Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:
> 
> > 
> > To better understand this myself, I just put a simple test case 
> > together using junit 4.1 with annotations and made use of the junit 
> > assertion calls e.g.
> > 
> > public class MyTest {
> >     @Test
> >     public void testSomething() {
> >         // this test will fail
> >         assertEquals( "numbers are same", 1, 2 );
> >     }
> > }
> > 
> > I then wrote a simple test harness to load the test class using 
> > reflection and invoke any methods starting with "test".
> > 
> >  public static void main(String[] args) throws Exception {
> >         Class testClass = Class.forName( "test.MyTest" );
> >         Object testObject = testClass.newInstance();
> >         Method method[] = testClass.getMethods();
> >         for (int i = 0; i < method.length; i++) {
> >             if (method[i].getName().startsWith("test")) {
> >                 System.out.println("Running " + method[i].getName());
> >                 try {
> >                     method[i].invoke( testObject );
> >                 } catch (Throwable th) {
> >                     th.printStackTrace();
> >                 }
> >             }
> >         }
> >     }
> > 
> > This ran the above test method and caught the following exception:
> > 
> > java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> > 
> > For me, this seems to demonstrate that using junit 4.1 style tests 
> > will allow people to call their tests from their own test harnesses 
> > without requiring junit-users to have to go to any special effort. The
> 
> > junit
> > Assert.* methods simply check some criteria and then call fail() if 
> > that criteria is false. The fail() method simply throws an
> AssertionError.
> > 
> > Writing the CTS tests using junit with annotations (rather than 
> > extending TestCase) does seem to provide everything required to allow 
> > users to run the tests outside of junit, albeit with a dependency on 
> > junit.jar but I don't see why that would be a problem for anyone? We 
> > could write our own versions of the assert* methods but they would do 
> > exactly the same thing as the junit implementation so this seems 
> > rather pointless.
> > 
> > My conclusion is that we should continue writing SDO CTS tests using 
> > junit, but ensure we use the annotation pattern rather than extending 
> > TestCase. Is everyone happy with this?
> > 
> > Thanks,
> > 
> > Andy.
> > 
> > 
> > -----Original Message-----
> > From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> > Sent: 17 April 2007 14:53
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
> > classes don't inherit from TestCase
> > 
> > Yes, I was about to write to the list on this subject. I'd like to 
> > understand more of how the test harness agnosticism was intended, and 
> > whether its really practical. As it stands there is still junit 
> > through and through,  in particular, each test method still references
> 
> > junit assertion calls.  Even if we could do assertions from 
> > annotations (as per JML pre and post conditions),  we still have all
> the junit imports.
> > If that were possible, then I guess each of the test methods could be 
> > invoked by something other than the junit test harness,  but they 
> > would have trouble asserting anything about the success of the method 
> > invocation,  since there are no artifacts available before or after 
> > the method invocation to make assertions about.
> > 
> > Kelvin
> > 
> > On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> > >
> > > If the goal is to make the tests "harness agnostic", then I don't 
> > > see much difference between a JUnit-specific inheritance dependency 
> > > and a JUnit-specific annotation dependency.  Is the annotation 
> > > dependency less troublesome for some reason?
> > >
> > >    Simon
> > >
> > > kelvin goodson wrote:
> > >
> > > > Thanks for this Andy,  I'll play with it tomorrow.
> > > >
> > > > Regards, Kelvin.
> > > >
> > > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > > >
> > > >>
> > > >>
> > > >> I believe you just need to annotate the setUp method with
> @Before. 
> > > >> This is described in the junit cookbook, here:
> > > >>
> > > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > > >>
> > > >> I'm currently working on submitting some more XSD test cases in 
> > > >> the
> > 
> > > >> CTS so I'll try this method out. Hopefully I can then remove the 
> > > >> current dependency on TestCase in those tests.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Andy.
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> > > Behalf
> > > >> Of kelvin goodson
> > > >> Sent: 16 April 2007 14:42
> > > >> To: tuscany-dev@ws.apache.org
> > > >> Cc: Robbie Minshall
> > > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > > classes
> > > >> don't inherit from TestCase
> > > >>
> > > >> Hi,
> > > >> I'm looking at doing some work in the CTS. I was looking back at 
> > > >> Robbie's attached description about how to keep the tests 
> > > >> "harness agnostic".  I'm assuming that this is still a goal of 
> > > >> the CTS although
> > > I
> > > >> may have missed something in my catching up. In my quest to make 
> > > >> the
> > > CTS
> > > >> better I note that a number of the test case classes still extend
> 
> > > >> the junit TestCase class.
> > > >> This is true for all test classes that have a setUp() method. One
> 
> > > >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> > > >> adding a setUp method to this class doesn't cause junit to invoke
> 
> > > >> it in my eclipse environment. I'm trying to work out whether I 
> > > >> should I expect a 4.1environment to discover and execute the 
> > > >> setUp method when junit is used in this way. I seem to have 
> > > >> Eclipse junit
> > 
> > > >> plugins for 3.8.1 and
> > > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer 
> > > >> much in the way of configuration, so I can't be sure I'm using 
> > > >> 4.1
> > behaviour.
> > > >>
> > > >> I really would like to be XSDSerializationTests to execute setUp 
> > > >> so
> > > that
> > > >> we can have a fresh HelperContext per test,  and I guess the easy
> 
> > > >> way out is to make the test class inherit from TestCase like the 
> > > >> others, but I'd prefer not to introduce the explicit dependency 
> > > >> on Junit if I can avoid it.
> > > >>
> > > >> Regards Kelvin.
> > > >>
> > > >>
> > > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > > >> >
> > > >> > This sounds quite good.
> > > >> >
> > > >> > I have written some test cases with Brian Murray which I would 
> > > >> > be
> > 
> > > >> > happy to contribute to tuscany.  Identifying duplication and 
> > > >> > differences in similar tests would probably be an intersting
> > > excercise
> > > >> right off the bat.
> > > >> >
> > > >> > One decision that we spent a little time mulling over was the 
> > > >> > framework to use for our test suite.  Originally we used the 
> > > >> > much
> > 
> > > >> > loved junit harness which worked well.  Different runtimes ( 
> > > >> > command line, J2EE Application Server, a Service Container ) 
> > > >> > have
> > 
> > > >> > different
> > > >> classloader hierarchies etc.
> > > >> > Without many modifications to the junit code it was difficult 
> > > >> > and
> > 
> > > >> > quite ugly testing SDO within the context of a variety of 
> > > >> > runtimes which the SDO APIs will be used.
> > > >> >
> > > >> > We took the approach of writing general test libraries which 
> > > >> > can then simply be called from a variety of test frameworks 
> > > >> > such as junit or a simple J2EE or SCA Application test harness.
> 
> > > >> > I like this approach
> > > for
> > > >>
> > > >> > keeping the actual test code very simple, allowing for 
> > > >> > integration a variety of test frameworks, and providing ability
> 
> > > >> > to test directly within the different runtimes people care
> about.
> > > >> >
> > > >> > Any thoughts on this ?
> > > >> >
> > > >> > Robbie
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > > >> > >
> > > >> > > Andy,
> > > >> > >   please attach them to the JIRA for this work and one of us 
> > > >> > > can pick them up, thanks.
> > > >> > > Best Regards, Kelvin.
> > > >> > >
> > > >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
> > wrote:
> > > >> > > >
> > > >> > > >
> > > >> > > > Hi Dan,
> > > >> > > >
> > > >> > > > I was previously working with Kelvin Goodson to donate some
> 
> > > >> > > > junit
> > > >> > > tests
> > > >> > > > on behalf of Rogue Wave Software.
> > > >> > > >
> > > >> > > > These tests are written purely to the SDO API and I have
> > > validated
> > > >> > > that
> > > >> > > > the tests do run against Tuscany as well as Rogue Wave's
> > > >> > > implementation.
> > > >> > > >
> > > >> > > >
> > > >> > > > Should I send the tests to Kelvin?
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > >
> > > >> > > > Andy.
> > > >> > > >
> > > >> > > > -----Original Message-----
> > > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > >> > > > Sent: 30 November 2006 17:44
> > > >> > > > To: Tuscany Developers; Tuscany Users
> > > >> > > > Subject: Proposal for a (Java) community test suite for SDO
> > > >> > > >
> > > >> > > > 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
> > > >> > > >
> > > >> > > >
> > > ------------------------------------------------------------------
> > > >> > > > --- To unsubscribe, e-mail: 
> > > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > > >> > > > For additional commands, e-mail: 
> > > >> > > > tuscany-dev-help@ws.apache.org
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > * * * 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
> > > >>
> > > >> -----------------------------------------------------------------
> > > >> --
> > > >> -- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >>
> > > >>
> > > >
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

Hi Frank,

The TestCase class defines setUp and tearDown as protected methods,
forcing the child class to also declare them as protected methods and
this means they can't be loaded using reflection.

Using junit 4.1 means we can declare the methods as public.

Thanks,

Andy.

-----Original Message-----
From: Frank Budinsky [mailto:frankb@ca.ibm.com] 
Sent: 17 April 2007 17:03
To: tuscany-dev@ws.apache.org
Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Hi Andy,

Maybe this is a stupid question (my junit ignorance showing through :-),
but couldn't you have run your simple test harness (main) even if MyTest
extended from TestCase? Is there something about having the base class
that prevents you from simply invoking the test methods directly?

Frank.

"Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:

> 
> To better understand this myself, I just put a simple test case 
> together using junit 4.1 with annotations and made use of the junit 
> assertion calls e.g.
> 
> public class MyTest {
>     @Test
>     public void testSomething() {
>         // this test will fail
>         assertEquals( "numbers are same", 1, 2 );
>     }
> }
> 
> I then wrote a simple test harness to load the test class using 
> reflection and invoke any methods starting with "test".
> 
>  public static void main(String[] args) throws Exception {
>         Class testClass = Class.forName( "test.MyTest" );
>         Object testObject = testClass.newInstance();
>         Method method[] = testClass.getMethods();
>         for (int i = 0; i < method.length; i++) {
>             if (method[i].getName().startsWith("test")) {
>                 System.out.println("Running " + method[i].getName());
>                 try {
>                     method[i].invoke( testObject );
>                 } catch (Throwable th) {
>                     th.printStackTrace();
>                 }
>             }
>         }
>     }
> 
> This ran the above test method and caught the following exception:
> 
> java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> 
> For me, this seems to demonstrate that using junit 4.1 style tests 
> will allow people to call their tests from their own test harnesses 
> without requiring junit-users to have to go to any special effort. The

> junit
> Assert.* methods simply check some criteria and then call fail() if 
> that criteria is false. The fail() method simply throws an
AssertionError.
> 
> Writing the CTS tests using junit with annotations (rather than 
> extending TestCase) does seem to provide everything required to allow 
> users to run the tests outside of junit, albeit with a dependency on 
> junit.jar but I don't see why that would be a problem for anyone? We 
> could write our own versions of the assert* methods but they would do 
> exactly the same thing as the junit implementation so this seems 
> rather pointless.
> 
> My conclusion is that we should continue writing SDO CTS tests using 
> junit, but ensure we use the annotation pattern rather than extending 
> TestCase. Is everyone happy with this?
> 
> Thanks,
> 
> Andy.
> 
> 
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 17 April 2007 14:53
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when 
> classes don't inherit from TestCase
> 
> Yes, I was about to write to the list on this subject. I'd like to 
> understand more of how the test harness agnosticism was intended, and 
> whether its really practical. As it stands there is still junit 
> through and through,  in particular, each test method still references

> junit assertion calls.  Even if we could do assertions from 
> annotations (as per JML pre and post conditions),  we still have all
the junit imports.
> If that were possible, then I guess each of the test methods could be 
> invoked by something other than the junit test harness,  but they 
> would have trouble asserting anything about the success of the method 
> invocation,  since there are no artifacts available before or after 
> the method invocation to make assertions about.
> 
> Kelvin
> 
> On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > If the goal is to make the tests "harness agnostic", then I don't 
> > see much difference between a JUnit-specific inheritance dependency 
> > and a JUnit-specific annotation dependency.  Is the annotation 
> > dependency less troublesome for some reason?
> >
> >    Simon
> >
> > kelvin goodson wrote:
> >
> > > Thanks for this Andy,  I'll play with it tomorrow.
> > >
> > > Regards, Kelvin.
> > >
> > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > >
> > >>
> > >>
> > >> I believe you just need to annotate the setUp method with
@Before. 
> > >> This is described in the junit cookbook, here:
> > >>
> > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > >>
> > >> I'm currently working on submitting some more XSD test cases in 
> > >> the
> 
> > >> CTS so I'll try this method out. Hopefully I can then remove the 
> > >> current dependency on TestCase in those tests.
> > >>
> > >> Thanks,
> > >>
> > >> Andy.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> > Behalf
> > >> Of kelvin goodson
> > >> Sent: 16 April 2007 14:42
> > >> To: tuscany-dev@ws.apache.org
> > >> Cc: Robbie Minshall
> > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes
> > >> don't inherit from TestCase
> > >>
> > >> Hi,
> > >> I'm looking at doing some work in the CTS. I was looking back at 
> > >> Robbie's attached description about how to keep the tests 
> > >> "harness agnostic".  I'm assuming that this is still a goal of 
> > >> the CTS although
> > I
> > >> may have missed something in my catching up. In my quest to make 
> > >> the
> > CTS
> > >> better I note that a number of the test case classes still extend

> > >> the junit TestCase class.
> > >> This is true for all test classes that have a setUp() method. One

> > >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> > >> adding a setUp method to this class doesn't cause junit to invoke

> > >> it in my eclipse environment. I'm trying to work out whether I 
> > >> should I expect a 4.1environment to discover and execute the 
> > >> setUp method when junit is used in this way. I seem to have 
> > >> Eclipse junit
> 
> > >> plugins for 3.8.1 and
> > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer 
> > >> much in the way of configuration, so I can't be sure I'm using 
> > >> 4.1
> behaviour.
> > >>
> > >> I really would like to be XSDSerializationTests to execute setUp 
> > >> so
> > that
> > >> we can have a fresh HelperContext per test,  and I guess the easy

> > >> way out is to make the test class inherit from TestCase like the 
> > >> others, but I'd prefer not to introduce the explicit dependency 
> > >> on Junit if I can avoid it.
> > >>
> > >> Regards Kelvin.
> > >>
> > >>
> > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > >> >
> > >> > This sounds quite good.
> > >> >
> > >> > I have written some test cases with Brian Murray which I would 
> > >> > be
> 
> > >> > happy to contribute to tuscany.  Identifying duplication and 
> > >> > differences in similar tests would probably be an intersting
> > excercise
> > >> right off the bat.
> > >> >
> > >> > One decision that we spent a little time mulling over was the 
> > >> > framework to use for our test suite.  Originally we used the 
> > >> > much
> 
> > >> > loved junit harness which worked well.  Different runtimes ( 
> > >> > command line, J2EE Application Server, a Service Container ) 
> > >> > have
> 
> > >> > different
> > >> classloader hierarchies etc.
> > >> > Without many modifications to the junit code it was difficult 
> > >> > and
> 
> > >> > quite ugly testing SDO within the context of a variety of 
> > >> > runtimes which the SDO APIs will be used.
> > >> >
> > >> > We took the approach of writing general test libraries which 
> > >> > can then simply be called from a variety of test frameworks 
> > >> > such as junit or a simple J2EE or SCA Application test harness.

> > >> > I like this approach
> > for
> > >>
> > >> > keeping the actual test code very simple, allowing for 
> > >> > integration a variety of test frameworks, and providing ability

> > >> > to test directly within the different runtimes people care
about.
> > >> >
> > >> > Any thoughts on this ?
> > >> >
> > >> > Robbie
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > >> > >
> > >> > > Andy,
> > >> > >   please attach them to the JIRA for this work and one of us 
> > >> > > can pick them up, thanks.
> > >> > > Best Regards, Kelvin.
> > >> > >
> > >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
> wrote:
> > >> > > >
> > >> > > >
> > >> > > > Hi Dan,
> > >> > > >
> > >> > > > I was previously working with Kelvin Goodson to donate some

> > >> > > > junit
> > >> > > tests
> > >> > > > on behalf of Rogue Wave Software.
> > >> > > >
> > >> > > > These tests are written purely to the SDO API and I have
> > validated
> > >> > > that
> > >> > > > the tests do run against Tuscany as well as Rogue Wave's
> > >> > > implementation.
> > >> > > >
> > >> > > >
> > >> > > > Should I send the tests to Kelvin?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Andy.
> > >> > > >
> > >> > > > -----Original Message-----
> > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > >> > > > Sent: 30 November 2006 17:44
> > >> > > > To: Tuscany Developers; Tuscany Users
> > >> > > > Subject: Proposal for a (Java) community test suite for SDO
> > >> > > >
> > >> > > > 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
> > >> > > >
> > >> > > >
> > ------------------------------------------------------------------
> > >> > > > --- To unsubscribe, e-mail: 
> > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > >> > > > For additional commands, e-mail: 
> > >> > > > tuscany-dev-help@ws.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > * * * 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
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

Hi Kelvin,
 
Robbie's main concern seems to be the ability to run the tests within a
J2EE or service container and he mentions "classloader hierarchy" issues
in his description. I'm guessing that the junit test runner uses a
custom class loader that caused problems when used within a J2EE
container. Now that we have established that the test cases themselves
can be invoked using reflection it seems that users should be able to
write code that calls the tests directly from their own, or from some
other testing framework, without any dependency on the junit test
runner.
 
Thanks,
 
Andy.

________________________________

From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On Behalf
Of kelvin goodson
Sent: 17 April 2007 16:59
To: Andy Grove
Cc: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase


Andy,
  that's really helpful.  I guess my problem was, and still is to some
extent, knowing whether reliance upon the junit.jar is acceptable to the
set of people we are trying to cater for.  I think your example has made
something clear to me though,  which is that our prime aim would be to
cater for the junit harness or anyone's home grown harness,  but not
necessarily another 3rd party harness.  Do you think this is what the
original intention of the meaning of "harness agnostic" is? 

Regards, Kelvin.



On 17/04/07, Andy Grove <gr...@roguewave.com> wrote: 


	To better understand this myself, I just put a simple test case
together
	using junit 4.1 with annotations and made use of the junit
assertion
	calls e.g.
	
	public class MyTest {
	    @Test
	    public void testSomething() { 
	        // this test will fail
	        assertEquals( "numbers are same", 1, 2 );
	    }
	}
	
	I then wrote a simple test harness to load the test class using
	reflection and invoke any methods starting with "test". 
	
	public static void main(String[] args) throws Exception {
	        Class testClass = Class.forName( "test.MyTest" );
	        Object testObject = testClass.newInstance();
	        Method method[] = testClass.getMethods();
	        for (int i = 0; i < method.length; i++) {
	            if (method[i].getName().startsWith("test")) {
	                System.out.println("Running " +
method[i].getName()); 
	                try {
	                    method[i].invoke( testObject );
	                } catch (Throwable th) {
	                    th.printStackTrace();
	                }
	            }
	        }
	    }
	
	This ran the above test method and caught the following
exception:
	
	java.lang.AssertionError: numbers are same expected:<1> but
was:<2>
	
	For me, this seems to demonstrate that using junit 4.1 style
tests will
	allow people to call their tests from their own test harnesses
without
	requiring junit-users to have to go to any special effort. The
junit
	Assert.* methods simply check some criteria and then call fail()
if that 
	criteria is false. The fail() method simply throws an
AssertionError.
	
	Writing the CTS tests using junit with annotations (rather than
	extending TestCase) does seem to provide everything required to
allow
	users to run the tests outside of junit, albeit with a
dependency on
	junit.jar but I don't see why that would be a problem for
anyone? We
	could write our own versions of the assert* methods but they
would do
	exactly the same thing as the junit implementation so this seems
rather
	pointless.
	
	My conclusion is that we should continue writing SDO CTS tests
using
	junit, but ensure we use the annotation pattern rather than
extending 
	TestCase. Is everyone happy with this?
	
	Thanks,
	
	Andy.
	
	
	-----Original Message-----
	From: kelvin goodson [mailto:kelvingoodson@gmail.com]
	Sent: 17 April 2007 14:53 
	To: tuscany-dev@ws.apache.org
	Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp
when
	classes don't inherit from TestCase
	
	Yes, I was about to write to the list on this subject. I'd like
to 
	understand more of how the test harness agnosticism was
intended, and
	whether its really practical. As it stands there is still junit
through
	and through,  in particular, each test method still references
junit
	assertion calls.  Even if we could do assertions from
annotations (as
	per JML pre and post conditions),  we still have all the junit
imports.
	If that were possible, then I guess each of the test methods
could be
	invoked by something other than the junit test harness,  but
they would
	have trouble asserting anything about the success of the method
	invocation,  since there are no artifacts available before or
after the
	method invocation to make assertions about. 
	
	Kelvin
	
	On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
	>
	> If the goal is to make the tests "harness agnostic", then I
don't see 
	> much difference between a JUnit-specific inheritance
dependency and a
	> JUnit-specific annotation dependency.  Is the annotation
dependency
	> less troublesome for some reason?
	>
	>    Simon 
	>
	> kelvin goodson wrote:
	>
	> > Thanks for this Andy,  I'll play with it tomorrow.
	> >
	> > Regards, Kelvin.
	> >
	> > On 16/04/07, Andy Grove < grove@roguewave.com
<ma...@roguewave.com> > wrote:
	> >
	> >>
	> >>
	> >> I believe you just need to annotate the setUp method with
@Before.
	> >> This is described in the junit cookbook, here: 
	> >>
	> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
	> >>
	> >> I'm currently working on submitting some more XSD test
cases in the 
	
	> >> CTS so I'll try this method out. Hopefully I can then
remove the
	> >> current dependency on TestCase in those tests.
	> >>
	> >> Thanks,
	> >>
	> >> Andy. 
	> >>
	> >>
	> >> -----Original Message-----
	> >> From: kelvingoodson@gmail.com
[mailto:kelvingoodson@gmail.com ] On
	> Behalf
	> >> Of kelvin goodson
	> >> Sent: 16 April 2007 14:42
	> >> To: tuscany-dev@ws.apache.org
	> >> Cc: Robbie Minshall 
	> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp
when
	> classes
	> >> don't inherit from TestCase
	> >>
	> >> Hi,
	> >> I'm looking at doing some work in the CTS. I was looking
back at 
	> >> Robbie's attached description about how to keep the tests
"harness
	> >> agnostic".  I'm assuming that this is still a goal of the
CTS
	> >> although
	> I
	> >> may have missed something in my catching up. In my quest to
make
	> >> the
	> CTS
	> >> better I note that a number of the test case classes still
extend
	> >> the junit TestCase class. 
	> >> This is true for all test classes that have a setUp()
method. One
	> >> that doesn't inherit from TestCase is XSDSerializationTest,
and
	> >> adding a setUp method to this class doesn't cause junit to
invoke 
	> >> it in my eclipse environment. I'm trying to work out
whether I
	> >> should I expect a 4.1environment to discover and execute
the setUp
	> >> method when junit is used in this way. I seem to have
Eclipse junit 
	
	> >> plugins for 3.8.1 and
	> >> 4.1.0.1 and the preferences tab for Junit doesn't seem to
offer
	> >> much in the way of configuration, so I can't be sure I'm
using 4.1
	behaviour.
	> >>
	> >> I really would like to be XSDSerializationTests to execute
setUp so
	> that
	> >> we can have a fresh HelperContext per test,  and I guess
the easy
	> >> way out is to make the test class inherit from TestCase
like the 
	> >> others, but I'd prefer not to introduce the explicit
dependency on
	> >> Junit if I can avoid it.
	> >>
	> >> Regards Kelvin.
	> >>
	> >>
	> >> On 07/12/06, Robbie Minshall < mykiwi@gmail.com> wrote:
	> >> >
	> >> > This sounds quite good.
	> >> >
	> >> > I have written some test cases with Brian Murray which I
would be 
	
	> >> > happy to contribute to tuscany.  Identifying duplication
and
	> >> > differences in similar tests would probably be an
intersting
	> excercise
	> >> right off the bat. 
	> >> >
	> >> > One decision that we spent a little time mulling over was
the
	> >> > framework to use for our test suite.  Originally we used
the much
	
	> >> > loved junit harness which worked well.  Different
runtimes ( 
	> >> > command line, J2EE Application Server, a Service
Container ) have
	
	> >> > different
	> >> classloader hierarchies etc.
	> >> > Without many modifications to the junit code it was
difficult and 
	
	> >> > quite ugly testing SDO within the context of a variety of
	> >> > runtimes which the SDO APIs will be used.
	> >> >
	> >> > We took the approach of writing general test libraries
which can 
	> >> > then simply be called from a variety of test frameworks
such as
	> >> > junit or a simple J2EE or SCA Application test harness.
I like
	> >> > this approach
	> for
	> >>
	> >> > keeping the actual test code very simple, allowing for
	> >> > integration a variety of test frameworks, and providing
ability
	> >> > to test directly within the different runtimes people
care about. 
	> >> >
	> >> > Any thoughts on this ?
	> >> >
	> >> > Robbie
	> >> >
	> >> >
	> >> >
	> >> >
	> >> > On 12/1/06, kelvin goodson < kelvingoodson@gmail.com >
wrote:
	> >> > >
	> >> > > Andy,
	> >> > >   please attach them to the JIRA for this work and one
of us 
	> >> > > can pick them up, thanks.
	> >> > > Best Regards, Kelvin.
	> >> > >
	> >> > > On 01/12/06, Andy Grove (Contractor) <
grove@roguewave.com <ma...@roguewave.com> >
	wrote:
	> >> > > >
	> >> > > >
	> >> > > > Hi Dan,
	> >> > > >
	> >> > > > I was previously working with Kelvin Goodson to
donate some 
	> >> > > > junit
	> >> > > tests
	> >> > > > on behalf of Rogue Wave Software.
	> >> > > >
	> >> > > > These tests are written purely to the SDO API and I
have 
	> validated
	> >> > > that
	> >> > > > the tests do run against Tuscany as well as Rogue
Wave's
	> >> > > implementation.
	> >> > > >
	> >> > > >
	> >> > > > Should I send the tests to Kelvin?
	> >> > > >
	> >> > > > Thanks,
	> >> > > >
	> >> > > > Andy. 
	> >> > > >
	> >> > > > -----Original Message-----
	> >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
	> >> > > > Sent: 30 November 2006 17:44
	> >> > > > To: Tuscany Developers; Tuscany Users
	> >> > > > Subject: Proposal for a (Java) community test suite
for SDO
	> >> > > >
	> >> > > > 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
	> >> > > >
	> >> > > >
	>
------------------------------------------------------------------ 
	> >> > > > --- To unsubscribe, e-mail:
	> >> > > > tuscany-dev-unsubscribe@ws.apache.org
	> >> > > > For additional commands, e-mail: 
	> >> > > > tuscany-dev-help@ws.apache.org
	> >> > > >
	> >> > > >
	> >> > >
	> >> > > 
	> >> >
	> >> >
	> >> > --
	> >> > * * * 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
	> >>
	> >>
-------------------------------------------------------------------
	> >> -- To unsubscribe, e-mail:
tuscany-dev-unsubscribe@ws.apache.org
	> >> For additional commands, e-mail:
tuscany-dev-help@ws.apache.org
	> >>
	> >>
	> > 
	>
	>
	>
	>
---------------------------------------------------------------------
	> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org 
	> For additional commands, e-mail:
tuscany-dev-help@ws.apache.org
	>
	>

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@thegoodsons.org.uk>.

Andy,
  that's really helpful.  I guess my problem was, and still is to some
extent, knowing whether reliance upon the junit.jar is acceptable to the set
of people we are trying to cater for.  I think your example has made
something clear to me though,  which is that our prime aim would be to cater
for the junit harness or anyone's home grown harness,  but not necessarily
another 3rd party harness.  Do you think this is what the original intention
of the meaning of "harness agnostic" is?

Regards, Kelvin.


On 17/04/07, Andy Grove <gr...@roguewave.com> wrote:
>
>
> To better understand this myself, I just put a simple test case together
> using junit 4.1 with annotations and made use of the junit assertion
> calls e.g.
>
> public class MyTest {
>     @Test
>     public void testSomething() {
>         // this test will fail
>         assertEquals( "numbers are same", 1, 2 );
>     }
> }
>
> I then wrote a simple test harness to load the test class using
> reflection and invoke any methods starting with "test".
>
> public static void main(String[] args) throws Exception {
>         Class testClass = Class.forName( "test.MyTest" );
>         Object testObject = testClass.newInstance();
>         Method method[] = testClass.getMethods();
>         for (int i = 0; i < method.length; i++) {
>             if (method[i].getName().startsWith("test")) {
>                 System.out.println("Running " + method[i].getName());
>                 try {
>                     method[i].invoke( testObject );
>                 } catch (Throwable th) {
>                     th.printStackTrace();
>                 }
>             }
>         }
>     }
>
> This ran the above test method and caught the following exception:
>
> java.lang.AssertionError: numbers are same expected:<1> but was:<2>
>
> For me, this seems to demonstrate that using junit 4.1 style tests will
> allow people to call their tests from their own test harnesses without
> requiring junit-users to have to go to any special effort. The junit
> Assert.* methods simply check some criteria and then call fail() if that
> criteria is false. The fail() method simply throws an AssertionError.
>
> Writing the CTS tests using junit with annotations (rather than
> extending TestCase) does seem to provide everything required to allow
> users to run the tests outside of junit, albeit with a dependency on
> junit.jar but I don't see why that would be a problem for anyone? We
> could write our own versions of the assert* methods but they would do
> exactly the same thing as the junit implementation so this seems rather
> pointless.
>
> My conclusion is that we should continue writing SDO CTS tests using
> junit, but ensure we use the annotation pattern rather than extending
> TestCase. Is everyone happy with this?
>
> Thanks,
>
> Andy.
>
>
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com]
> Sent: 17 April 2007 14:53
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
>
> Yes, I was about to write to the list on this subject. I'd like to
> understand more of how the test harness agnosticism was intended, and
> whether its really practical. As it stands there is still junit through
> and through,  in particular, each test method still references junit
> assertion calls.  Even if we could do assertions from annotations (as
> per JML pre and post conditions),  we still have all the junit imports.
> If that were possible, then I guess each of the test methods could be
> invoked by something other than the junit test harness,  but they would
> have trouble asserting anything about the success of the method
> invocation,  since there are no artifacts available before or after the
> method invocation to make assertions about.
>
> Kelvin
>
> On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > If the goal is to make the tests "harness agnostic", then I don't see
> > much difference between a JUnit-specific inheritance dependency and a
> > JUnit-specific annotation dependency.  Is the annotation dependency
> > less troublesome for some reason?
> >
> >    Simon
> >
> > kelvin goodson wrote:
> >
> > > Thanks for this Andy,  I'll play with it tomorrow.
> > >
> > > Regards, Kelvin.
> > >
> > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > >
> > >>
> > >>
> > >> I believe you just need to annotate the setUp method with @Before.
> > >> This is described in the junit cookbook, here:
> > >>
> > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > >>
> > >> I'm currently working on submitting some more XSD test cases in the
>
> > >> CTS so I'll try this method out. Hopefully I can then remove the
> > >> current dependency on TestCase in those tests.
> > >>
> > >> Thanks,
> > >>
> > >> Andy.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> > Behalf
> > >> Of kelvin goodson
> > >> Sent: 16 April 2007 14:42
> > >> To: tuscany-dev@ws.apache.org
> > >> Cc: Robbie Minshall
> > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes
> > >> don't inherit from TestCase
> > >>
> > >> Hi,
> > >> I'm looking at doing some work in the CTS. I was looking back at
> > >> Robbie's attached description about how to keep the tests "harness
> > >> agnostic".  I'm assuming that this is still a goal of the CTS
> > >> although
> > I
> > >> may have missed something in my catching up. In my quest to make
> > >> the
> > CTS
> > >> better I note that a number of the test case classes still extend
> > >> the junit TestCase class.
> > >> This is true for all test classes that have a setUp() method. One
> > >> that doesn't inherit from TestCase is XSDSerializationTest,  and
> > >> adding a setUp method to this class doesn't cause junit to invoke
> > >> it in my eclipse environment. I'm trying to work out whether I
> > >> should I expect a 4.1environment to discover and execute the setUp
> > >> method when junit is used in this way. I seem to have Eclipse junit
>
> > >> plugins for 3.8.1 and
> > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer
> > >> much in the way of configuration, so I can't be sure I'm using 4.1
> behaviour.
> > >>
> > >> I really would like to be XSDSerializationTests to execute setUp so
> > that
> > >> we can have a fresh HelperContext per test,  and I guess the easy
> > >> way out is to make the test class inherit from TestCase like the
> > >> others, but I'd prefer not to introduce the explicit dependency on
> > >> Junit if I can avoid it.
> > >>
> > >> Regards Kelvin.
> > >>
> > >>
> > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > >> >
> > >> > This sounds quite good.
> > >> >
> > >> > I have written some test cases with Brian Murray which I would be
>
> > >> > happy to contribute to tuscany.  Identifying duplication and
> > >> > differences in similar tests would probably be an intersting
> > excercise
> > >> right off the bat.
> > >> >
> > >> > One decision that we spent a little time mulling over was the
> > >> > framework to use for our test suite.  Originally we used the much
>
> > >> > loved junit harness which worked well.  Different runtimes (
> > >> > command line, J2EE Application Server, a Service Container ) have
>
> > >> > different
> > >> classloader hierarchies etc.
> > >> > Without many modifications to the junit code it was difficult and
>
> > >> > quite ugly testing SDO within the context of a variety of
> > >> > runtimes which the SDO APIs will be used.
> > >> >
> > >> > We took the approach of writing general test libraries which can
> > >> > then simply be called from a variety of test frameworks such as
> > >> > junit or a simple J2EE or SCA Application test harness.  I like
> > >> > this approach
> > for
> > >>
> > >> > keeping the actual test code very simple, allowing for
> > >> > integration a variety of test frameworks, and providing ability
> > >> > to test directly within the different runtimes people care about.
> > >> >
> > >> > Any thoughts on this ?
> > >> >
> > >> > Robbie
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > >> > >
> > >> > > Andy,
> > >> > >   please attach them to the JIRA for this work and one of us
> > >> > > can pick them up, thanks.
> > >> > > Best Regards, Kelvin.
> > >> > >
> > >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
> wrote:
> > >> > > >
> > >> > > >
> > >> > > > Hi Dan,
> > >> > > >
> > >> > > > I was previously working with Kelvin Goodson to donate some
> > >> > > > junit
> > >> > > tests
> > >> > > > on behalf of Rogue Wave Software.
> > >> > > >
> > >> > > > These tests are written purely to the SDO API and I have
> > validated
> > >> > > that
> > >> > > > the tests do run against Tuscany as well as Rogue Wave's
> > >> > > implementation.
> > >> > > >
> > >> > > >
> > >> > > > Should I send the tests to Kelvin?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Andy.
> > >> > > >
> > >> > > > -----Original Message-----
> > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > >> > > > Sent: 30 November 2006 17:44
> > >> > > > To: Tuscany Developers; Tuscany Users
> > >> > > > Subject: Proposal for a (Java) community test suite for SDO
> > >> > > >
> > >> > > > 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
> > >> > > >
> > >> > > >
> > ------------------------------------------------------------------
> > >> > > > --- To unsubscribe, e-mail:
> > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > >> > > > For additional commands, e-mail:
> > >> > > > tuscany-dev-help@ws.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > * * * 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
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Frank Budinsky <fr...@ca.ibm.com>.

Hi Andy,

Maybe this is a stupid question (my junit ignorance showing through :-), 
but couldn't you have run your simple test harness (main) even if MyTest 
extended from TestCase? Is there something about having the base class 
that prevents you from simply invoking the test methods directly?

Frank.

"Andy Grove" <gr...@roguewave.com> wrote on 04/17/2007 11:21:49 AM:

> 
> To better understand this myself, I just put a simple test case together
> using junit 4.1 with annotations and made use of the junit assertion
> calls e.g.
> 
> public class MyTest {
>     @Test
>     public void testSomething() {
>         // this test will fail
>         assertEquals( "numbers are same", 1, 2 );
>     }
> }
> 
> I then wrote a simple test harness to load the test class using
> reflection and invoke any methods starting with "test". 
> 
>  public static void main(String[] args) throws Exception {
>         Class testClass = Class.forName( "test.MyTest" );
>         Object testObject = testClass.newInstance();
>         Method method[] = testClass.getMethods();
>         for (int i = 0; i < method.length; i++) {
>             if (method[i].getName().startsWith("test")) {
>                 System.out.println("Running " + method[i].getName());
>                 try {
>                     method[i].invoke( testObject );
>                 } catch (Throwable th) {
>                     th.printStackTrace();
>                 }
>             }
>         }
>     }
> 
> This ran the above test method and caught the following exception:
> 
> java.lang.AssertionError: numbers are same expected:<1> but was:<2>
> 
> For me, this seems to demonstrate that using junit 4.1 style tests will
> allow people to call their tests from their own test harnesses without
> requiring junit-users to have to go to any special effort. The junit
> Assert.* methods simply check some criteria and then call fail() if that
> criteria is false. The fail() method simply throws an AssertionError. 
> 
> Writing the CTS tests using junit with annotations (rather than
> extending TestCase) does seem to provide everything required to allow
> users to run the tests outside of junit, albeit with a dependency on
> junit.jar but I don't see why that would be a problem for anyone? We
> could write our own versions of the assert* methods but they would do
> exactly the same thing as the junit implementation so this seems rather
> pointless.
> 
> My conclusion is that we should continue writing SDO CTS tests using
> junit, but ensure we use the annotation pattern rather than extending
> TestCase. Is everyone happy with this?
> 
> Thanks,
> 
> Andy.
> 
> 
> -----Original Message-----
> From: kelvin goodson [mailto:kelvingoodson@gmail.com] 
> Sent: 17 April 2007 14:53
> To: tuscany-dev@ws.apache.org
> Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes don't inherit from TestCase
> 
> Yes, I was about to write to the list on this subject. I'd like to
> understand more of how the test harness agnosticism was intended, and
> whether its really practical. As it stands there is still junit through
> and through,  in particular, each test method still references junit
> assertion calls.  Even if we could do assertions from annotations (as
> per JML pre and post conditions),  we still have all the junit imports.
> If that were possible, then I guess each of the test methods could be
> invoked by something other than the junit test harness,  but they would
> have trouble asserting anything about the success of the method
> invocation,  since there are no artifacts available before or after the
> method invocation to make assertions about.
> 
> Kelvin
> 
> On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> > If the goal is to make the tests "harness agnostic", then I don't see 
> > much difference between a JUnit-specific inheritance dependency and a 
> > JUnit-specific annotation dependency.  Is the annotation dependency 
> > less troublesome for some reason?
> >
> >    Simon
> >
> > kelvin goodson wrote:
> >
> > > Thanks for this Andy,  I'll play with it tomorrow.
> > >
> > > Regards, Kelvin.
> > >
> > > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> > >
> > >>
> > >>
> > >> I believe you just need to annotate the setUp method with @Before. 
> > >> This is described in the junit cookbook, here:
> > >>
> > >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> > >>
> > >> I'm currently working on submitting some more XSD test cases in the
> 
> > >> CTS so I'll try this method out. Hopefully I can then remove the 
> > >> current dependency on TestCase in those tests.
> > >>
> > >> Thanks,
> > >>
> > >> Andy.
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> > Behalf
> > >> Of kelvin goodson
> > >> Sent: 16 April 2007 14:42
> > >> To: tuscany-dev@ws.apache.org
> > >> Cc: Robbie Minshall
> > >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> > classes
> > >> don't inherit from TestCase
> > >>
> > >> Hi,
> > >> I'm looking at doing some work in the CTS. I was looking back at 
> > >> Robbie's attached description about how to keep the tests "harness 
> > >> agnostic".  I'm assuming that this is still a goal of the CTS 
> > >> although
> > I
> > >> may have missed something in my catching up. In my quest to make 
> > >> the
> > CTS
> > >> better I note that a number of the test case classes still extend 
> > >> the junit TestCase class.
> > >> This is true for all test classes that have a setUp() method. One 
> > >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> > >> adding a setUp method to this class doesn't cause junit to invoke 
> > >> it in my eclipse environment. I'm trying to work out whether I 
> > >> should I expect a 4.1environment to discover and execute the setUp 
> > >> method when junit is used in this way. I seem to have Eclipse junit
> 
> > >> plugins for 3.8.1 and
> > >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer 
> > >> much in the way of configuration, so I can't be sure I'm using 4.1
> behaviour.
> > >>
> > >> I really would like to be XSDSerializationTests to execute setUp so
> > that
> > >> we can have a fresh HelperContext per test,  and I guess the easy 
> > >> way out is to make the test class inherit from TestCase like the 
> > >> others, but I'd prefer not to introduce the explicit dependency on 
> > >> Junit if I can avoid it.
> > >>
> > >> Regards Kelvin.
> > >>
> > >>
> > >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> > >> >
> > >> > This sounds quite good.
> > >> >
> > >> > I have written some test cases with Brian Murray which I would be
> 
> > >> > happy to contribute to tuscany.  Identifying duplication and 
> > >> > differences in similar tests would probably be an intersting
> > excercise
> > >> right off the bat.
> > >> >
> > >> > One decision that we spent a little time mulling over was the 
> > >> > framework to use for our test suite.  Originally we used the much
> 
> > >> > loved junit harness which worked well.  Different runtimes ( 
> > >> > command line, J2EE Application Server, a Service Container ) have
> 
> > >> > different
> > >> classloader hierarchies etc.
> > >> > Without many modifications to the junit code it was difficult and
> 
> > >> > quite ugly testing SDO within the context of a variety of 
> > >> > runtimes which the SDO APIs will be used.
> > >> >
> > >> > We took the approach of writing general test libraries which can 
> > >> > then simply be called from a variety of test frameworks such as 
> > >> > junit or a simple J2EE or SCA Application test harness.  I like 
> > >> > this approach
> > for
> > >>
> > >> > keeping the actual test code very simple, allowing for 
> > >> > integration a variety of test frameworks, and providing ability 
> > >> > to test directly within the different runtimes people care about.
> > >> >
> > >> > Any thoughts on this ?
> > >> >
> > >> > Robbie
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > >> > >
> > >> > > Andy,
> > >> > >   please attach them to the JIRA for this work and one of us 
> > >> > > can pick them up, thanks.
> > >> > > Best Regards, Kelvin.
> > >> > >
> > >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
> wrote:
> > >> > > >
> > >> > > >
> > >> > > > Hi Dan,
> > >> > > >
> > >> > > > I was previously working with Kelvin Goodson to donate some 
> > >> > > > junit
> > >> > > tests
> > >> > > > on behalf of Rogue Wave Software.
> > >> > > >
> > >> > > > These tests are written purely to the SDO API and I have
> > validated
> > >> > > that
> > >> > > > the tests do run against Tuscany as well as Rogue Wave's
> > >> > > implementation.
> > >> > > >
> > >> > > >
> > >> > > > Should I send the tests to Kelvin?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Andy.
> > >> > > >
> > >> > > > -----Original Message-----
> > >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > >> > > > Sent: 30 November 2006 17:44
> > >> > > > To: Tuscany Developers; Tuscany Users
> > >> > > > Subject: Proposal for a (Java) community test suite for SDO
> > >> > > >
> > >> > > > 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
> > >> > > >
> > >> > > >
> > ------------------------------------------------------------------
> > >> > > > --- To unsubscribe, e-mail: 
> > >> > > > tuscany-dev-unsubscribe@ws.apache.org
> > >> > > > For additional commands, e-mail: 
> > >> > > > tuscany-dev-help@ws.apache.org
> > >> > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > * * * 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
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

To better understand this myself, I just put a simple test case together
using junit 4.1 with annotations and made use of the junit assertion
calls e.g.

public class MyTest {
    @Test
    public void testSomething() {
        // this test will fail
        assertEquals( "numbers are same", 1, 2 );
    }
}

I then wrote a simple test harness to load the test class using
reflection and invoke any methods starting with "test". 

 public static void main(String[] args) throws Exception {
        Class testClass = Class.forName( "test.MyTest" );
        Object testObject = testClass.newInstance();
        Method method[] = testClass.getMethods();
        for (int i = 0; i < method.length; i++) {
            if (method[i].getName().startsWith("test")) {
                System.out.println("Running " + method[i].getName());
                try {
                    method[i].invoke( testObject );
                } catch (Throwable th) {
                    th.printStackTrace();
                }
            }
        }
    }

This ran the above test method and caught the following exception:

java.lang.AssertionError: numbers are same expected:<1> but was:<2>

For me, this seems to demonstrate that using junit 4.1 style tests will
allow people to call their tests from their own test harnesses without
requiring junit-users to have to go to any special effort. The junit
Assert.* methods simply check some criteria and then call fail() if that
criteria is false. The fail() method simply throws an AssertionError. 

Writing the CTS tests using junit with annotations (rather than
extending TestCase) does seem to provide everything required to allow
users to run the tests outside of junit, albeit with a dependency on
junit.jar but I don't see why that would be a problem for anyone? We
could write our own versions of the assert* methods but they would do
exactly the same thing as the junit implementation so this seems rather
pointless.

My conclusion is that we should continue writing SDO CTS tests using
junit, but ensure we use the annotation pattern rather than extending
TestCase. Is everyone happy with this?

Thanks,

Andy.


-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com] 
Sent: 17 April 2007 14:53
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through
and through,  in particular, each test method still references junit
assertion calls.  Even if we could do assertions from annotations (as
per JML pre and post conditions),  we still have all the junit imports.
If that were possible, then I guess each of the test methods could be
invoked by something other than the junit test harness,  but they would
have trouble asserting anything about the success of the method
invocation,  since there are no artifacts available before or after the
method invocation to make assertions about.

Kelvin

On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't see 
> much difference between a JUnit-specific inheritance dependency and a 
> JUnit-specific annotation dependency.  Is the annotation dependency 
> less troublesome for some reason?
>
>    Simon
>
> kelvin goodson wrote:
>
> > Thanks for this Andy,  I'll play with it tomorrow.
> >
> > Regards, Kelvin.
> >
> > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before. 
> >> This is described in the junit cookbook, here:
> >>
> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> >>
> >> I'm currently working on submitting some more XSD test cases in the

> >> CTS so I'll try this method out. Hopefully I can then remove the 
> >> current dependency on TestCase in those tests.
> >>
> >> Thanks,
> >>
> >> Andy.
> >>
> >>
> >> -----Original Message-----
> >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> Behalf
> >> Of kelvin goodson
> >> Sent: 16 April 2007 14:42
> >> To: tuscany-dev@ws.apache.org
> >> Cc: Robbie Minshall
> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes
> >> don't inherit from TestCase
> >>
> >> Hi,
> >> I'm looking at doing some work in the CTS. I was looking back at 
> >> Robbie's attached description about how to keep the tests "harness 
> >> agnostic".  I'm assuming that this is still a goal of the CTS 
> >> although
> I
> >> may have missed something in my catching up. In my quest to make 
> >> the
> CTS
> >> better I note that a number of the test case classes still extend 
> >> the junit TestCase class.
> >> This is true for all test classes that have a setUp() method. One 
> >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> >> adding a setUp method to this class doesn't cause junit to invoke 
> >> it in my eclipse environment. I'm trying to work out whether I 
> >> should I expect a 4.1environment to discover and execute the setUp 
> >> method when junit is used in this way. I seem to have Eclipse junit

> >> plugins for 3.8.1 and
> >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer 
> >> much in the way of configuration, so I can't be sure I'm using 4.1
behaviour.
> >>
> >> I really would like to be XSDSerializationTests to execute setUp so
> that
> >> we can have a fresh HelperContext per test,  and I guess the easy 
> >> way out is to make the test class inherit from TestCase like the 
> >> others, but I'd prefer not to introduce the explicit dependency on 
> >> Junit if I can avoid it.
> >>
> >> Regards Kelvin.
> >>
> >>
> >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> >> >
> >> > This sounds quite good.
> >> >
> >> > I have written some test cases with Brian Murray which I would be

> >> > happy to contribute to tuscany.  Identifying duplication and 
> >> > differences in similar tests would probably be an intersting
> excercise
> >> right off the bat.
> >> >
> >> > One decision that we spent a little time mulling over was the 
> >> > framework to use for our test suite.  Originally we used the much

> >> > loved junit harness which worked well.  Different runtimes ( 
> >> > command line, J2EE Application Server, a Service Container ) have

> >> > different
> >> classloader hierarchies etc.
> >> > Without many modifications to the junit code it was difficult and

> >> > quite ugly testing SDO within the context of a variety of 
> >> > runtimes which the SDO APIs will be used.
> >> >
> >> > We took the approach of writing general test libraries which can 
> >> > then simply be called from a variety of test frameworks such as 
> >> > junit or a simple J2EE or SCA Application test harness.  I like 
> >> > this approach
> for
> >>
> >> > keeping the actual test code very simple, allowing for 
> >> > integration a variety of test frameworks, and providing ability 
> >> > to test directly within the different runtimes people care about.
> >> >
> >> > Any thoughts on this ?
> >> >
> >> > Robbie
> >> >
> >> >
> >> >
> >> >
> >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> >> > >
> >> > > Andy,
> >> > >   please attach them to the JIRA for this work and one of us 
> >> > > can pick them up, thanks.
> >> > > Best Regards, Kelvin.
> >> > >
> >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
wrote:
> >> > > >
> >> > > >
> >> > > > Hi Dan,
> >> > > >
> >> > > > I was previously working with Kelvin Goodson to donate some 
> >> > > > junit
> >> > > tests
> >> > > > on behalf of Rogue Wave Software.
> >> > > >
> >> > > > These tests are written purely to the SDO API and I have
> validated
> >> > > that
> >> > > > the tests do run against Tuscany as well as Rogue Wave's
> >> > > implementation.
> >> > > >
> >> > > >
> >> > > > Should I send the tests to Kelvin?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Andy.
> >> > > >
> >> > > > -----Original Message-----
> >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> >> > > > Sent: 30 November 2006 17:44
> >> > > > To: Tuscany Developers; Tuscany Users
> >> > > > Subject: Proposal for a (Java) community test suite for SDO
> >> > > >
> >> > > > 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
> >> > > >
> >> > > >
> ------------------------------------------------------------------
> >> > > > --- To unsubscribe, e-mail: 
> >> > > > tuscany-dev-unsubscribe@ws.apache.org
> >> > > > For additional commands, e-mail: 
> >> > > > tuscany-dev-help@ws.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > * * * 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
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

Kelvin,

Is it possible to get a copy of Robbie's document that you mentioned in
your earlier email? I didn't see an attachment.

Thanks,

Andy.

-----Original Message-----
From: kelvin goodson [mailto:kelvingoodson@gmail.com] 
Sent: 17 April 2007 14:53
To: tuscany-dev@ws.apache.org
Subject: Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
classes don't inherit from TestCase

Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through
and through,  in particular, each test method still references junit
assertion calls.  Even if we could do assertions from annotations (as
per JML pre and post conditions),  we still have all the junit imports.
If that were possible, then I guess each of the test methods could be
invoked by something other than the junit test harness,  but they would
have trouble asserting anything about the success of the method
invocation,  since there are no artifacts available before or after the
method invocation to make assertions about.

Kelvin

On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't see 
> much difference between a JUnit-specific inheritance dependency and a 
> JUnit-specific annotation dependency.  Is the annotation dependency 
> less troublesome for some reason?
>
>    Simon
>
> kelvin goodson wrote:
>
> > Thanks for this Andy,  I'll play with it tomorrow.
> >
> > Regards, Kelvin.
> >
> > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before. 
> >> This is described in the junit cookbook, here:
> >>
> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> >>
> >> I'm currently working on submitting some more XSD test cases in the

> >> CTS so I'll try this method out. Hopefully I can then remove the 
> >> current dependency on TestCase in those tests.
> >>
> >> Thanks,
> >>
> >> Andy.
> >>
> >>
> >> -----Original Message-----
> >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> Behalf
> >> Of kelvin goodson
> >> Sent: 16 April 2007 14:42
> >> To: tuscany-dev@ws.apache.org
> >> Cc: Robbie Minshall
> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes
> >> don't inherit from TestCase
> >>
> >> Hi,
> >> I'm looking at doing some work in the CTS. I was looking back at 
> >> Robbie's attached description about how to keep the tests "harness 
> >> agnostic".  I'm assuming that this is still a goal of the CTS 
> >> although
> I
> >> may have missed something in my catching up. In my quest to make 
> >> the
> CTS
> >> better I note that a number of the test case classes still extend 
> >> the junit TestCase class.
> >> This is true for all test classes that have a setUp() method. One 
> >> that doesn't inherit from TestCase is XSDSerializationTest,  and 
> >> adding a setUp method to this class doesn't cause junit to invoke 
> >> it in my eclipse environment. I'm trying to work out whether I 
> >> should I expect a 4.1environment to discover and execute the setUp 
> >> method when junit is used in this way. I seem to have Eclipse junit

> >> plugins for 3.8.1 and
> >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer 
> >> much in the way of configuration, so I can't be sure I'm using 4.1
behaviour.
> >>
> >> I really would like to be XSDSerializationTests to execute setUp so
> that
> >> we can have a fresh HelperContext per test,  and I guess the easy 
> >> way out is to make the test class inherit from TestCase like the 
> >> others, but I'd prefer not to introduce the explicit dependency on 
> >> Junit if I can avoid it.
> >>
> >> Regards Kelvin.
> >>
> >>
> >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> >> >
> >> > This sounds quite good.
> >> >
> >> > I have written some test cases with Brian Murray which I would be

> >> > happy to contribute to tuscany.  Identifying duplication and 
> >> > differences in similar tests would probably be an intersting
> excercise
> >> right off the bat.
> >> >
> >> > One decision that we spent a little time mulling over was the 
> >> > framework to use for our test suite.  Originally we used the much

> >> > loved junit harness which worked well.  Different runtimes ( 
> >> > command line, J2EE Application Server, a Service Container ) have

> >> > different
> >> classloader hierarchies etc.
> >> > Without many modifications to the junit code it was difficult and

> >> > quite ugly testing SDO within the context of a variety of 
> >> > runtimes which the SDO APIs will be used.
> >> >
> >> > We took the approach of writing general test libraries which can 
> >> > then simply be called from a variety of test frameworks such as 
> >> > junit or a simple J2EE or SCA Application test harness.  I like 
> >> > this approach
> for
> >>
> >> > keeping the actual test code very simple, allowing for 
> >> > integration a variety of test frameworks, and providing ability 
> >> > to test directly within the different runtimes people care about.
> >> >
> >> > Any thoughts on this ?
> >> >
> >> > Robbie
> >> >
> >> >
> >> >
> >> >
> >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> >> > >
> >> > > Andy,
> >> > >   please attach them to the JIRA for this work and one of us 
> >> > > can pick them up, thanks.
> >> > > Best Regards, Kelvin.
> >> > >
> >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com>
wrote:
> >> > > >
> >> > > >
> >> > > > Hi Dan,
> >> > > >
> >> > > > I was previously working with Kelvin Goodson to donate some 
> >> > > > junit
> >> > > tests
> >> > > > on behalf of Rogue Wave Software.
> >> > > >
> >> > > > These tests are written purely to the SDO API and I have
> validated
> >> > > that
> >> > > > the tests do run against Tuscany as well as Rogue Wave's
> >> > > implementation.
> >> > > >
> >> > > >
> >> > > > Should I send the tests to Kelvin?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Andy.
> >> > > >
> >> > > > -----Original Message-----
> >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> >> > > > Sent: 30 November 2006 17:44
> >> > > > To: Tuscany Developers; Tuscany Users
> >> > > > Subject: Proposal for a (Java) community test suite for SDO
> >> > > >
> >> > > > 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
> >> > > >
> >> > > >
> ------------------------------------------------------------------
> >> > > > --- To unsubscribe, e-mail: 
> >> > > > tuscany-dev-unsubscribe@ws.apache.org
> >> > > > For additional commands, e-mail: 
> >> > > > tuscany-dev-help@ws.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > * * * 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
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@gmail.com>.

Yes, I was about to write to the list on this subject. I'd like to
understand more of how the test harness agnosticism was intended, and
whether its really practical. As it stands there is still junit through and
through,  in particular, each test method still references junit assertion
calls.  Even if we could do assertions from annotations (as per JML pre and
post conditions),  we still have all the junit imports.  If that were
possible, then I guess each of the test methods could be invoked by
something other than the junit test harness,  but they would have trouble
asserting anything about the success of the method invocation,  since there
are no artifacts available before or after the method invocation to make
assertions about.

Kelvin

On 17/04/07, Simon Nash <na...@hursley.ibm.com> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't
> see much difference between a JUnit-specific inheritance dependency
> and a JUnit-specific annotation dependency.  Is the annotation
> dependency less troublesome for some reason?
>
>    Simon
>
> kelvin goodson wrote:
>
> > Thanks for this Andy,  I'll play with it tomorrow.
> >
> > Regards, Kelvin.
> >
> > On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before. This
> >> is described in the junit cookbook, here:
> >>
> >> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
> >>
> >> I'm currently working on submitting some more XSD test cases in the CTS
> >> so I'll try this method out. Hopefully I can then remove the current
> >> dependency on TestCase in those tests.
> >>
> >> Thanks,
> >>
> >> Andy.
> >>
> >>
> >> -----Original Message-----
> >> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On
> Behalf
> >> Of kelvin goodson
> >> Sent: 16 April 2007 14:42
> >> To: tuscany-dev@ws.apache.org
> >> Cc: Robbie Minshall
> >> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when
> classes
> >> don't inherit from TestCase
> >>
> >> Hi,
> >> I'm looking at doing some work in the CTS. I was looking back at
> >> Robbie's attached description about how to keep the tests "harness
> >> agnostic".  I'm assuming that this is still a goal of the CTS although
> I
> >> may have missed something in my catching up. In my quest to make the
> CTS
> >> better I note that a number of the test case classes still extend the
> >> junit TestCase class.
> >> This is true for all test classes that have a setUp() method. One that
> >> doesn't inherit from TestCase is XSDSerializationTest,  and adding a
> >> setUp method to this class doesn't cause junit to invoke it in my
> >> eclipse environment. I'm trying to work out whether I should I expect a
> >> 4.1environment to discover and execute the setUp method when junit is
> >> used in this way. I seem to have Eclipse junit plugins for 3.8.1 and
> >> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in
> >> the way of configuration, so I can't be sure I'm using 4.1 behaviour.
> >>
> >> I really would like to be XSDSerializationTests to execute setUp so
> that
> >> we can have a fresh HelperContext per test,  and I guess the easy way
> >> out is to make the test class inherit from TestCase like the others,
> >> but I'd prefer not to introduce the explicit dependency on Junit if I
> >> can avoid it.
> >>
> >> Regards Kelvin.
> >>
> >>
> >> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> >> >
> >> > This sounds quite good.
> >> >
> >> > I have written some test cases with Brian Murray which I would be
> >> > happy to contribute to tuscany.  Identifying duplication and
> >> > differences in similar tests would probably be an intersting
> excercise
> >> right off the bat.
> >> >
> >> > One decision that we spent a little time mulling over was the
> >> > framework to use for our test suite.  Originally we used the much
> >> > loved junit harness which worked well.  Different runtimes ( command
> >> > line, J2EE Application Server, a Service Container ) have different
> >> classloader hierarchies etc.
> >> > Without many modifications to the junit code it was difficult and
> >> > quite ugly testing SDO within the context of a variety of runtimes
> >> > which the SDO APIs will be used.
> >> >
> >> > We took the approach of writing general test libraries which can then
> >> > simply be called from a variety of test frameworks such as junit or a
> >> > simple J2EE or SCA Application test harness.  I like this approach
> for
> >>
> >> > keeping the actual test code very simple, allowing for integration a
> >> > variety of test frameworks, and providing ability to test directly
> >> > within the different runtimes people care about.
> >> >
> >> > Any thoughts on this ?
> >> >
> >> > Robbie
> >> >
> >> >
> >> >
> >> >
> >> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> >> > >
> >> > > Andy,
> >> > >   please attach them to the JIRA for this work and one of us can
> >> > > pick them up, thanks.
> >> > > Best Regards, Kelvin.
> >> > >
> >> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com> wrote:
> >> > > >
> >> > > >
> >> > > > Hi Dan,
> >> > > >
> >> > > > I was previously working with Kelvin Goodson to donate some junit
> >> > > tests
> >> > > > on behalf of Rogue Wave Software.
> >> > > >
> >> > > > These tests are written purely to the SDO API and I have
> validated
> >> > > that
> >> > > > the tests do run against Tuscany as well as Rogue Wave's
> >> > > implementation.
> >> > > >
> >> > > >
> >> > > > Should I send the tests to Kelvin?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Andy.
> >> > > >
> >> > > > -----Original Message-----
> >> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> >> > > > Sent: 30 November 2006 17:44
> >> > > > To: Tuscany Developers; Tuscany Users
> >> > > > Subject: Proposal for a (Java) community test suite for SDO
> >> > > >
> >> > > > 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
> >> > > >
> >> > > >
> ------------------------------------------------------------------
> >> > > > --- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > * * * 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
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Simon Nash <na...@hursley.ibm.com>.

If the goal is to make the tests "harness agnostic", then I don't
see much difference between a JUnit-specific inheritance dependency
and a JUnit-specific annotation dependency.  Is the annotation
dependency less troublesome for some reason?

   Simon

kelvin goodson wrote:

> Thanks for this Andy,  I'll play with it tomorrow.
> 
> Regards, Kelvin.
> 
> On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
> 
>>
>>
>> I believe you just need to annotate the setUp method with @Before. This
>> is described in the junit cookbook, here:
>>
>> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
>>
>> I'm currently working on submitting some more XSD test cases in the CTS
>> so I'll try this method out. Hopefully I can then remove the current
>> dependency on TestCase in those tests.
>>
>> Thanks,
>>
>> Andy.
>>
>>
>> -----Original Message-----
>> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On Behalf
>> Of kelvin goodson
>> Sent: 16 April 2007 14:42
>> To: tuscany-dev@ws.apache.org
>> Cc: Robbie Minshall
>> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes
>> don't inherit from TestCase
>>
>> Hi,
>> I'm looking at doing some work in the CTS. I was looking back at
>> Robbie's attached description about how to keep the tests "harness
>> agnostic".  I'm assuming that this is still a goal of the CTS although I
>> may have missed something in my catching up. In my quest to make the CTS
>> better I note that a number of the test case classes still extend the
>> junit TestCase class.
>> This is true for all test classes that have a setUp() method. One that
>> doesn't inherit from TestCase is XSDSerializationTest,  and adding a
>> setUp method to this class doesn't cause junit to invoke it in my
>> eclipse environment. I'm trying to work out whether I should I expect a
>> 4.1environment to discover and execute the setUp method when junit is
>> used in this way. I seem to have Eclipse junit plugins for 3.8.1 and
>> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in
>> the way of configuration, so I can't be sure I'm using 4.1 behaviour.
>>
>> I really would like to be XSDSerializationTests to execute setUp so that
>> we can have a fresh HelperContext per test,  and I guess the easy way
>> out is to make the test class inherit from TestCase like the others,
>> but I'd prefer not to introduce the explicit dependency on Junit if I
>> can avoid it.
>>
>> Regards Kelvin.
>>
>>
>> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
>> >
>> > This sounds quite good.
>> >
>> > I have written some test cases with Brian Murray which I would be
>> > happy to contribute to tuscany.  Identifying duplication and
>> > differences in similar tests would probably be an intersting excercise
>> right off the bat.
>> >
>> > One decision that we spent a little time mulling over was the
>> > framework to use for our test suite.  Originally we used the much
>> > loved junit harness which worked well.  Different runtimes ( command
>> > line, J2EE Application Server, a Service Container ) have different
>> classloader hierarchies etc.
>> > Without many modifications to the junit code it was difficult and
>> > quite ugly testing SDO within the context of a variety of runtimes
>> > which the SDO APIs will be used.
>> >
>> > We took the approach of writing general test libraries which can then
>> > simply be called from a variety of test frameworks such as junit or a
>> > simple J2EE or SCA Application test harness.  I like this approach for
>>
>> > keeping the actual test code very simple, allowing for integration a
>> > variety of test frameworks, and providing ability to test directly
>> > within the different runtimes people care about.
>> >
>> > Any thoughts on this ?
>> >
>> > Robbie
>> >
>> >
>> >
>> >
>> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
>> > >
>> > > Andy,
>> > >   please attach them to the JIRA for this work and one of us can
>> > > pick them up, thanks.
>> > > Best Regards, Kelvin.
>> > >
>> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com> wrote:
>> > > >
>> > > >
>> > > > Hi Dan,
>> > > >
>> > > > I was previously working with Kelvin Goodson to donate some junit
>> > > tests
>> > > > on behalf of Rogue Wave Software.
>> > > >
>> > > > These tests are written purely to the SDO API and I have validated
>> > > that
>> > > > the tests do run against Tuscany as well as Rogue Wave's
>> > > implementation.
>> > > >
>> > > >
>> > > > Should I send the tests to Kelvin?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Andy.
>> > > >
>> > > > -----Original Message-----
>> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
>> > > > Sent: 30 November 2006 17:44
>> > > > To: Tuscany Developers; Tuscany Users
>> > > > Subject: Proposal for a (Java) community test suite for SDO
>> > > >
>> > > > 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
>> > > >
>> > > > ------------------------------------------------------------------
>> > > > --- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > * * * 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
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by kelvin goodson <ke...@gmail.com>.

Thanks for this Andy,  I'll play with it tomorrow.

Regards, Kelvin.

On 16/04/07, Andy Grove <gr...@roguewave.com> wrote:
>
>
> I believe you just need to annotate the setUp method with @Before. This
> is described in the junit cookbook, here:
>
> http://junit.sourceforge.net/doc/cookbook/cookbook.htm
>
> I'm currently working on submitting some more XSD test cases in the CTS
> so I'll try this method out. Hopefully I can then remove the current
> dependency on TestCase in those tests.
>
> Thanks,
>
> Andy.
>
>
> -----Original Message-----
> From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On Behalf
> Of kelvin goodson
> Sent: 16 April 2007 14:42
> To: tuscany-dev@ws.apache.org
> Cc: Robbie Minshall
> Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes
> don't inherit from TestCase
>
> Hi,
> I'm looking at doing some work in the CTS. I was looking back at
> Robbie's attached description about how to keep the tests "harness
> agnostic".  I'm assuming that this is still a goal of the CTS although I
> may have missed something in my catching up. In my quest to make the CTS
> better I note that a number of the test case classes still extend the
> junit TestCase class.
> This is true for all test classes that have a setUp() method. One that
> doesn't inherit from TestCase is XSDSerializationTest,  and adding a
> setUp method to this class doesn't cause junit to invoke it in my
> eclipse environment. I'm trying to work out whether I should I expect a
> 4.1environment to discover and execute the setUp method when junit is
> used in this way. I seem to have Eclipse junit plugins for 3.8.1 and
> 4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in
> the way of configuration, so I can't be sure I'm using 4.1 behaviour.
>
> I really would like to be XSDSerializationTests to execute setUp so that
> we can have a fresh HelperContext per test,  and I guess the easy way
> out is to make the test class inherit from TestCase like the others,
> but I'd prefer not to introduce the explicit dependency on Junit if I
> can avoid it.
>
> Regards Kelvin.
>
>
> On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
> >
> > This sounds quite good.
> >
> > I have written some test cases with Brian Murray which I would be
> > happy to contribute to tuscany.  Identifying duplication and
> > differences in similar tests would probably be an intersting excercise
> right off the bat.
> >
> > One decision that we spent a little time mulling over was the
> > framework to use for our test suite.  Originally we used the much
> > loved junit harness which worked well.  Different runtimes ( command
> > line, J2EE Application Server, a Service Container ) have different
> classloader hierarchies etc.
> > Without many modifications to the junit code it was difficult and
> > quite ugly testing SDO within the context of a variety of runtimes
> > which the SDO APIs will be used.
> >
> > We took the approach of writing general test libraries which can then
> > simply be called from a variety of test frameworks such as junit or a
> > simple J2EE or SCA Application test harness.  I like this approach for
>
> > keeping the actual test code very simple, allowing for integration a
> > variety of test frameworks, and providing ability to test directly
> > within the different runtimes people care about.
> >
> > Any thoughts on this ?
> >
> > Robbie
> >
> >
> >
> >
> > On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> > >
> > > Andy,
> > >   please attach them to the JIRA for this work and one of us can
> > > pick them up, thanks.
> > > Best Regards, Kelvin.
> > >
> > > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com> wrote:
> > > >
> > > >
> > > > Hi Dan,
> > > >
> > > > I was previously working with Kelvin Goodson to donate some junit
> > > tests
> > > > on behalf of Rogue Wave Software.
> > > >
> > > > These tests are written purely to the SDO API and I have validated
> > > that
> > > > the tests do run against Tuscany as well as Rogue Wave's
> > > implementation.
> > > >
> > > >
> > > > Should I send the tests to Kelvin?
> > > >
> > > > Thanks,
> > > >
> > > > Andy.
> > > >
> > > > -----Original Message-----
> > > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > > Sent: 30 November 2006 17:44
> > > > To: Tuscany Developers; Tuscany Users
> > > > Subject: Proposal for a (Java) community test suite for SDO
> > > >
> > > > 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
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > * * * 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't inherit from TestCase

Posted by Andy Grove <gr...@roguewave.com>.

I believe you just need to annotate the setUp method with @Before. This
is described in the junit cookbook, here:

http://junit.sourceforge.net/doc/cookbook/cookbook.htm

I'm currently working on submitting some more XSD test cases in the CTS
so I'll try this method out. Hopefully I can then remove the current
dependency on TestCase in those tests.

Thanks,

Andy.
 

-----Original Message-----
From: kelvingoodson@gmail.com [mailto:kelvingoodson@gmail.com] On Behalf
Of kelvin goodson
Sent: 16 April 2007 14:42
To: tuscany-dev@ws.apache.org
Cc: Robbie Minshall
Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes
don't inherit from TestCase

Hi,
 I'm looking at doing some work in the CTS. I was looking back at
Robbie's attached description about how to keep the tests "harness
agnostic".  I'm assuming that this is still a goal of the CTS although I
may have missed something in my catching up. In my quest to make the CTS
better I note that a number of the test case classes still extend the
junit TestCase class.
This is true for all test classes that have a setUp() method. One that
doesn't inherit from TestCase is XSDSerializationTest,  and adding a
setUp method to this class doesn't cause junit to invoke it in my
eclipse environment. I'm trying to work out whether I should I expect a
4.1environment to discover and execute the setUp method when junit is
used in this way. I seem to have Eclipse junit plugins for 3.8.1 and
4.1.0.1 and the preferences tab for Junit doesn't seem to offer much in
the way of configuration, so I can't be sure I'm using 4.1 behaviour.

I really would like to be XSDSerializationTests to execute setUp so that
we can have a fresh HelperContext per test,  and I guess the easy way
out is to make the test class inherit from TestCase like the others,
but I'd prefer not to introduce the explicit dependency on Junit if I
can avoid it.

Regards Kelvin.


On 07/12/06, Robbie Minshall <my...@gmail.com> wrote:
>
> This sounds quite good.
>
> I have written some test cases with Brian Murray which I would be 
> happy to contribute to tuscany.  Identifying duplication and 
> differences in similar tests would probably be an intersting excercise
right off the bat.
>
> One decision that we spent a little time mulling over was the 
> framework to use for our test suite.  Originally we used the much 
> loved junit harness which worked well.  Different runtimes ( command 
> line, J2EE Application Server, a Service Container ) have different
classloader hierarchies etc.
> Without many modifications to the junit code it was difficult and 
> quite ugly testing SDO within the context of a variety of runtimes 
> which the SDO APIs will be used.
>
> We took the approach of writing general test libraries which can then 
> simply be called from a variety of test frameworks such as junit or a 
> simple J2EE or SCA Application test harness.  I like this approach for

> keeping the actual test code very simple, allowing for integration a 
> variety of test frameworks, and providing ability to test directly 
> within the different runtimes people care about.
>
> Any thoughts on this ?
>
> Robbie
>
>
>
>
> On 12/1/06, kelvin goodson <kelvingoodson@gmail.com > wrote:
> >
> > Andy,
> >   please attach them to the JIRA for this work and one of us can 
> > pick them up, thanks.
> > Best Regards, Kelvin.
> >
> > On 01/12/06, Andy Grove (Contractor) <gr...@roguewave.com> wrote:
> > >
> > >
> > > Hi Dan,
> > >
> > > I was previously working with Kelvin Goodson to donate some junit
> > tests
> > > on behalf of Rogue Wave Software.
> > >
> > > These tests are written purely to the SDO API and I have validated
> > that
> > > the tests do run against Tuscany as well as Rogue Wave's
> > implementation.
> > >
> > >
> > > Should I send the tests to Kelvin?
> > >
> > > Thanks,
> > >
> > > Andy.
> > >
> > > -----Original Message-----
> > > From: Dan Murphy [mailto:dm.subs@googlemail.com ]
> > > Sent: 30 November 2006 17:44
> > > To: Tuscany Developers; Tuscany Users
> > > Subject: Proposal for a (Java) community test suite for SDO
> > >
> > > 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
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> >
>
>
> --
> * * * 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

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org