Return-Path: <jeff.martin@synamic.co.uk>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 64113 invoked from network); 8 Aug 2000 11:42:07 -0000
Received: from demon-gw.synamic.co.uk (HELO speedy.synamic.co.uk)
 (194.70.193.66)
  by locus.apache.org with SMTP; 8 Aug 2000 11:42:07 -0000
Received: by speedy.synamic.co.uk with Internet Mail Service (5.5.2650.21)
	id <QC138WZG>; Tue, 8 Aug 2000 12:41:26 +0100
Message-ID: <A3470D904559D311A7A000A0C9E4D8415E8043@speedy.synamic.co.uk>
From: Jeff Martin <jeff.martin@synamic.co.uk>
To: "'ant-dev@jakarta.apache.org'" <ant-dev@jakarta.apache.org>
Subject: RE: [PATCH] Pattern based Junit tests
Date: Tue, 8 Aug 2000 12:41:06 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

That looks totally cool, I think that's definately a good way to be handling
things. Has anyone got documentation on the go for the junit stuff yet?

-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@bost.de]
Sent: 08 August 2000 12:23
To: ant-dev@jakarta.apache.org
Subject: Re: [PATCH] Pattern based Junit tests


>>>>> "JM" == Jeff Martin <jeff.martin@synamic.co.uk> writes:

 JM> This is a patch which adds a new subtask called batchtest to the
 JM> junit task.

I'm in the course of rewriting most of the JUnit stuff at the moment,
I'm going to include the functionality but will base it on the
include/exclude mechanism like the one for filesets. I.e.

<batchtest dir="${java.src}>
  <include name="**/test_*.java" />
</batchtest>

is this OK?

Other things I'm going to change:

* add if and unless attributes to test (and possibly batchtest?). Should
behave like the ones for targets and include/exclude.

* remove the string "default" from the attributes of JUnit.

* remove printxml everywhere (see <formatter> below). Remove
printsummary from <test>.

* remove defaultoutfile. All this does is hand a default filename to
the XML Formatter - which we should do anyway if the user want XML
output and doesn't specify a filename.

* add a nested <formatter> tag, both to <junit> as well as to <test>
(and <batchtest>?).

<junit>
  <formatter type="xml">
</junit>

will do the same as defaultprintxml did.

<junit>
  <formatter type="plain">
</junit>

will produce plain text files with the same content the XML files had.

<junit>
  <formatter classname="my.own.Formatter" />
</junit>

will use my.own.Formatter, which must implement
org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter.

What do you think of these ideas? Did I remove something that will
break your setup - and doesn't provide a different way to achieve the
same?

Stefan