ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: FW: antunit branch for 1.6.x compatibility
Date Fri, 27 Oct 2006 09:31:14 GMT
Vladimir Egorov wrote:
>> -----Original Message-----
>> From: Steve Loughran []
>> 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:
> id
>> es.pdf
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message