Great!
Waiting for the patch.
Thanks,
Konstantin.
-----Original Message-----
From: Thomas Haas [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 27, 2000 11:28 AM
To: [EMAIL PROTECTED]
Subject: Re: JUnit task and friends
[EMAIL PROTECTED] (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:[EMAIL PROTECTED] <mailto:
> [EMAIL PROTECTED]>]
> Sent: Tuesday, June 27, 2000 10:33 AM
> To: [EMAIL PROTECTED]
> Subject: Re: JUnit task and friends
>
>
> [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
> > Work: [EMAIL PROTECTED]
> > Web: www.cortexebusiness.com.au
> >
> >
> > -----Original Message-----
> > From: Konstantin Nazarenko [mailto:[EMAIL PROTECTED] <
> mailto:[EMAIL PROTECTED]>]
> > Sent: Wednesday, 28 June 2000 0:14
> > To: 'Thomas Haas'; [EMAIL PROTECTED]
> > 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:[EMAIL PROTECTED] <mailto:
> [EMAIL PROTECTED]>]
> > Sent: Wednesday, April 19, 2000 4:09 PM
> > To: [EMAIL PROTECTED]
> > 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
>
>
