Vladimir Egorov wrote:
-----Original Message-----
From: Steve Loughran [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 26, 2006 9:33 AM
To: Ant Developers List
Subject: Re: FW: antunit branch for 1.6.x compatibility
Vladimir Egorov wrote:
Sorry for a bit of a messy entry into the list. I did not realize
that
using html email could be a problem. Thanks Stephan for pointing
this
out.
My inquiry is in connection with TestLogic project on CodeShare.
Could you please expand a little on TestLogic for the rest of the
Ant
developers?
TestLogic is an initiative by BEA Systems Inc. Tools team to provide
an
open source testing framework for the enterprise. The flavor of this
effort is to provide the glue that would tie together existing
frameworks (e.g. JUnit) in a consistent manageable way. Over time,
we
want to cover the breadth of the enterprise testing needs, based on
our
knowledge of BEA Systems Inc. testing needs. The project is so far a
private project on CodeShare. We are planning to open source when we
reach some point of maturity and can get clearance, hopefully within
2-4
month.
That's interesting. Have you seen the work I'm doing with deployment
of
junit3/4/testng+other frameworks and merging of results
No we haven't seen your work. The 'merging of results' does sound like
the kind of thing we are doing; it would be interesting to learn more
from the links you kindly provided.
uniform serialization of results for over-RMI comms, and (b) some
evolving XML format. For (b) I've got marked up XHTML, but am thinking
of how to use Atom to integrate results, a polling app and log data:
http://smartfrog.org/presentations/distributed_testing_with_smartfrog_sl
id
es.pdf
http://video.google.co.uk/videosearch?q=smartfrog
We currently want to stay away from RMI as in our prior experience
framework RMI sometimes interferes with server RMI in unexpected ways.
Also we want to support non-java frameworks (e.g. WinRunner) via single
protocol.
We use RMI internally, but yes, we do want a wire protocol that is
better long haul. One thing I'm thinking of for results is to publish
stuff as Atom, but maybe also add a RESTy way of running Tests. I'd back
this up with a servlet that could be deployed inside a web app/EAR, to
do cactus-style running of tests inside an app server. I think cactus is
wonderful, but dont see why you need to instantiate every test class
inside the client-side machine, except for compatibility with legacy
test runners.
Uniformity of both the java format and the xml output would be very
beneficial, and putting the stuff into antunit and <junit> and
<junit4>
is part of my goal.
We are trying to with existing frameworks with minimum modifications.
For example, we support <junit> by adding a custom nested <formatter>
(listener) that knows how to talk to us.
I was looking at tweaking that myself, but its complex because forked
junit instantiates the listener in the remote process, where its hard to
configure. With a cross-process run (in which the forked test run feeds
results as serialized data or XML) you dont need that; the custom
listener can live in ant's process.
If we come up with a new XML format, I'd just patch it in to <junit>,
<antunit> and presumably, the junit4 task as and when I sit down to
write it.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
