Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes
 don't inherit from TestCase
Date: Tue, 17 Apr 2007 08:11:02 -0600
Message-ID: 
 <D730FF7CEDDCA64483F9E99D999A158B0116F0FB@qxvcexch01.ad.quovadx.com>
In-Reply-To: <9deac9fd0704170652s21f67003of03278c88fb46e0e@mail.gmail.com>
Thread-Topic: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes
 don't inherit from TestCase
Thread-Index: AceA9/HepI14rEJ6S82QTtOCVIJJigAAf7OA
References: <9deac9fd0704160641i459ad4b9k50b5819e02221d2a@mail.gmail.com>
 <D730FF7CEDDCA64483F9E99D999A158B011156B3@qxvcexch01.ad.quovadx.com>
 <9deac9fd0704161005w28d4a8ccs669097f704c498a6@mail.gmail.com>
 <4624CCFA.5020502@hursley.ibm.com>
 <9deac9fd0704170652s21f67003of03278c88fb46e0e@mail.gmail.com>
From: "Andy Grove" <grove@roguewave.com>
To: <tuscany-dev@ws.apache.org>, <kelvin@thegoodsons.org.uk>


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]=20
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 <nash@hursley.ibm.com> wrote:
>
> If the goal is to make the tests "harness agnostic", then I don't see=20
> much difference between a JUnit-specific inheritance dependency and a=20
> JUnit-specific annotation dependency.  Is the annotation dependency=20
> 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> wrote:
> >
> >>
> >>
> >> I believe you just need to annotate the setUp method with @Before.=20
> >> 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=20
> >> 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=20
> >> Robbie's attached description about how to keep the tests "harness=20
> >> agnostic".  I'm assuming that this is still a goal of the CTS=20
> >> although
> I
> >> may have missed something in my catching up. In my quest to make=20
> >> the
> CTS
> >> better I note that a number of the test case classes still extend=20
> >> the junit TestCase class.
> >> This is true for all test classes that have a setUp() method. One=20
> >> that doesn't inherit from TestCase is XSDSerializationTest,  and=20
> >> adding a setUp method to this class doesn't cause junit to invoke=20
> >> it in my eclipse environment. I'm trying to work out whether I=20
> >> should I expect a 4.1environment to discover and execute the setUp=20
> >> 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=20
> >> 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=20
> >> way out is to make the test class inherit from TestCase like the=20
> >> others, but I'd prefer not to introduce the explicit dependency on=20
> >> 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=20
> >> > 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=20
> >> > framework to use for our test suite.  Originally we used the much

> >> > loved junit harness which worked well.  Different runtimes (=20
> >> > 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=20
> >> > runtimes which the SDO APIs will be used.
> >> >
> >> > We took the approach of writing general test libraries which can=20
> >> > then simply be called from a variety of test frameworks such as=20
> >> > junit or a simple J2EE or SCA Application test harness.  I like=20
> >> > this approach
> for
> >>
> >> > keeping the actual test code very simple, allowing for=20
> >> > integration a variety of test frameworks, and providing ability=20
> >> > 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=20
> >> > > can pick them up, thanks.
> >> > > Best Regards, Kelvin.
> >> > >
> >> > > On 01/12/06, Andy Grove (Contractor) <grove@roguewave.com>
wrote:
> >> > > >
> >> > > >
> >> > > > Hi Dan,
> >> > > >
> >> > > > I was previously working with Kelvin Goodson to donate some=20
> >> > > > 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=20
> >> > > > service
> >> > > data
> >> > > > objects (SDO CTS) implementations written in Java. Based on=20
> >> > > > feedback from an earlier post this seems to be the first=20
> >> > > > logical step in getting interoperable SDO implementations in=20
> >> > > > all languages. I can see this leading to an interoperability=20
> >> > > > test suite to check serialisation between implementations=20
> >> > > > also works (across languages and implementations).
> >> > > >
> >> > > > Proposal for Community Test Suite (CTS) for SDO Develop a=20
> >> > > > test suite to validate an SDO implementation behaves as=20
> >> > > > expected, according to the community's understanding of the=20
> >> > > > SDO
> >> specification.
> >> > > > Should
> >> > > > the specification appear ambiguous or unclear then the=20
> >> > > > community will decide what to do; it may decide to test the=20
> >> > > > 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=20
> >> > > > run this against Tuscany, the test suite will only test=20
> >> > > > things that
> we
> >>
> >> > > > think any implementation should support.
> >> > > >
> >> > > > The SDO CTS will enable developers to choose or switch SDO=20
> >> > > > implementations without the concern of having to re-code a=20
> >> > > > significant proportion of their application due to=20
> >> > > > differences between implementations. This community test=20
> >> > > > suite will first focus on areas identified important to=20
> >> > > > developers of
> >> > >
> >> > > > SDO
> >> > > > applications. SDO users feedback and involvement will be=20
> >> > > > 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=20
> >> > > > to be a validation
> >> > > or
> >> > > > compliancy suite.
> >> > > >
> >> > > > To encourage everyone with an interest in SDO to contribute=20
> >> > > > 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=20
> >> > > > 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,=20
> >> > > > 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=20
> >> > > > concerns, comments or suggestions please append them...
> >> > > >
> >> > > > Thanks in advance to all those who volunteer :) Dan
> >> > > >
> >> > > >
> ------------------------------------------------------------------
> >> > > > --- To unsubscribe, e-mail:=20
> >> > > > tuscany-dev-unsubscribe@ws.apache.org
> >> > > > For additional commands, e-mail:=20
> >> > > > tuscany-dev-help@ws.apache.org
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > * * * Charlie * * *
> >> > Check out some pics of little Charlie at=20
> >> > http://www.flickr.com/photos/83388211@N00/sets/
> >> >
> >> > Check out Charlie's al crapo blog at=20
> >> > 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