ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Nazarenko <KNazare...@BlueRipple.com>
Subject RE: JUnit task and friends
Date Tue, 27 Jun 2000 17:44:42 GMT
Great!
Waiting for the patch.

Thanks,
Konstantin.

-----Original Message-----
From: Thomas Haas [mailto:thomas.haas@softwired-inc.com]
Sent: Tuesday, June 27, 2000 11:28 AM
To: ant-dev@jakarta.apache.org
Subject: Re: JUnit task and friends


KNazarenko@BlueRipple.com (Konstantin Nazarenko) wrote:
> 
> Hi,
> I agree that testing against jar files does not work. But as I know 
> the main idea of JUnit (according to Creators) is to run ALL test at 
> the same time at least once a day. So QA person could run the test and

> analyze (using output information) what class has failed. 
> 
> Again, Imagine situation when QA department is small or not present at

> all and developers are creating Test classes by themselves. I think it

> is reasonable to have a bunch of Test classes rather then one BIG Test

> suite.
> 
> So probably it is reasonable to create more abstract JUnitTask and 
> then couple of more specific?
> 

Sure. Not everybody works the same way. If you or anybody else feels 
like adding this, please do so. I will not, because I do not need and 
cannot use it, because we work the way I explained before.

I'll put a JUnit patch up, so you can start adding MatchingTask. OK?

- tom


> Thanks,
> Konstantin
> 
> -----Original Message-----
> From: Thomas Haas [mailto:thomas.haas@softwired-inc.com <mailto: 
> thomas.haas@softwired-inc.com>]
> Sent: Tuesday, June 27, 2000 10:33 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: JUnit task and friends
> 
> 
> 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 < 
> 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 <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