ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Haas <thomas.h...@softwired-inc.com>
Subject Re: JUnit task and friends
Date Tue, 27 Jun 2000 14:32:37 GMT
conor@m64.com (Conor MacNeill) wrote:
> 
> JUnit has its own concept for handling collections for tests, namely suites.
> Do we want to overlap that?

I can see, that it may be handy to run all tests defined in classes 
named Test*. This would be **/Test*. If others like it, it could be 
done. I do not like it for myself because:
- Testing and QA are tightly coupled, and QA wants to know EXACTLY which 
tests are run.
- Our tests usually run against jar files (QA wants to know exactly 
which clas, which version), so matching does not work in its current 
incarnation.

- tom


> --
> Conor MacNeill
> Home: conor@m64.com
> Work: conor@cortexebusiness.com.au
> Web:  www.cortexebusiness.com.au
> 
> 
> -----Original Message-----
> From: Konstantin Nazarenko [mailto:KNazarenko@BlueRipple.com]
> Sent: Wednesday, 28 June 2000 0:14
> To: 'Thomas Haas'; ant-dev@jakarta.apache.org
> Subject: JUnit task and friends
> 
> 
> 
> Hi All,
> I am quite new in ANT/JUnit programming but I think it is a great idea to
> have Unit Testing framework (JUnit), which runs automatically using ANT.
> So I have a suggestion concerning Thomas?s realization of JUnitTask. I think
> it will be very helpful to derive JUnitTask   from MatchingTask (not from
> Task). It will give us the possibility to specify what files we are going to
> test.
> For example: we have a bunch of test classes, lets say _t*.class. Using
> MatchingTask it is possible to perform recursive, automated ANT TEST through
> the entire tree of classes.
> 
> Is this idea worth to work out or is it already implemented in some other
> way?
> 
> Thanks,
> Konstantin.
> -----Original Message-----
> From: Thomas Haas [mailto:thomas.haas@softwired-inc.com]
> Sent: Wednesday, April 19, 2000 4:09 PM
> To: ant-dev@jakarta.apache.org
> Subject: JUnit task and friends
> 
> 
> Upon request a snapshot of the current JUnit task is provided.
> Except Path.java everything resides in the optional package for now. The
> development got stuck due to the current discussion about the future design
> of ant. The JUnit task needs a proposal to replace Exec with a more
> extensible and reusable version offering various other feattures (see
> OExec.java).
> 
> 
> NOTE
> - This version writes the output to RUNNING-TEST-<testname>.xml. The file is
> renamed to TEST-<testname>.xml on success and ERROR-<testname>.xml on
> failure. This has been done to be compatible with our old, makefile based
> build system and will be obsolete, once the backends are converted to XML.
> - Tests are not run if a file TEST-<testname>.xml already exists. This is
> used for fix/build/test cycles prior to committing changes to the
> repository.
> - Both features may be made confifurable and/or optional, as they may not be
> needed by everybody.
> - I started implementing only my features, as it first looked like beside
> Stefan Bodewig nobody is interested in this. It looks like I was wrong,
> great.
> 
> 
> TODO
> - provide a specialiced classloader to extend the classpath at runtime
> differently for every junit task.
> - in addition to the XML output provide ASCII output.
> - I am not 100% happy with the XML structure, but it is fine right now.
> - Docu
> 
> 
> As long as it JUnit is not part of ant, I will collect patches and submit
> them to the list.
> 
> Let me know, what you think.
> - tom



Mime
View raw message