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: domain of kelvingoodson@gmail.com
 designates 209.85.132.247 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth;
        b=Qg67VC/Xs0CyTI2Cojyyu2wgSseCvT/TOTjDWyHhJbqd8unwjwIwUOe7xYGzDxlC4xyy7NCdbmFdkv12hucIpwpNCnGjZu+OkWq1BlC96EGxEvPKzcffP6BtfugHZTKXC9MnnsYd9qwzj/Plpxqfdna6tI3WvfOG/TSDqGjvu3U=
Message-ID: <9deac9fd0704160641i459ad4b9k50b5819e02221d2a@mail.gmail.com>
Date: Mon, 16 Apr 2007 14:41:46 +0100
From: "kelvin goodson" <kelvin@thegoodsons.org.uk>
Sender: kelvingoodson@gmail.com
To: tuscany-dev@ws.apache.org
Subject: [Java SDO CTS] Junit 4.1 pattern for calling setUp when classes don't
 inherit from TestCase
Cc: "Robbie Minshall" <mykiwi@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_65465_32741534.1176730906157"

------=_Part_65465_32741534.1176730906157
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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> 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

------=_Part_65465_32741534.1176730906157--