junit-devel — junit developers

[Junit-devel] JUnit & Eclipse...

[<ri...@ya...>]

Hello,

On the Eclipse (http://www.eclipse.org) newsgroup I posted that
I was interested in making some plugins to integrate JUnit into
it. My idea was to be able to trigger an action "Run tests" when
the selected class in the JDT extended TestCase or had a suite()
method available. Christophe Elek from OTI replied that he would
not be surprised if Erich Gamma was already thinking on doing
such a thing.
Erich, can you shed some light on this one? Are you already
developing this? Do you want help, feedback on preliminary
versions, etc? Always glad to help!

Ringo

=====
NOTE: My email address has changed!!
Bigfoot is changing their service offering. The free service is limited to 25 emails a day which is too low for me. I will stop using Bigfoot which means that both my BigFoot email addresses will become invalid after 15 September 2001. Here are the new email adresses:
HOME: rid...@us...
WORK: Rin...@me...

____________________________________________________________
Nokia Game is on again. 
Go to http://uk.yahoo.com/nokiagame/ and join the new
all media adventure before November 3rd.

RE: [Junit-devel] Test2 interface

[Kent B. <ken...@cs...>]

Our usual procedures would require such a dance. I'm willing to risk just
adding getName() to Test and seeing what happens.

Kent

RE: [Junit-devel] Test2 interface

[Erik M. <em...@ge...>]

TestDecorator and DoubleTestCase in TestImplementorTest would have to
implement it.  Are
there any objections to just adding getName to Test now?

Erik

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Thursday, October 25, 2001 1:15 PM
> To: JUnit-Devel
> Subject: [Junit-devel] Test2 interface
>
>
> Proposition for adding the getName() method to the Test interface:
>
> * in the version 3.8
> - create a Test2 that extends Test and adds getName()
> - mark Test as deprecated
> - TestSuite and TestCase now implement Test2
> - _but_ all clients ui still work with the Test interface
>
> ... in the meantime users using 3.8 and having home-made classes that
> implement the Test interface update their code...
>
> * in the version 3.9
> - delete the Test.java file
> - modify all clients to only recognize the Test2 interface
>
> It's also possible to add a method to the Test interface directly but
> some users will have their tests broken.
>
> The only requirement is to first use 3.8 before 3.9.
>
> -Vladimir
>
> --
> Vladimir Bossicard
> www.bossicard.com
>
>
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel

[Junit-devel] CVS activity emailed to this list

[Erik M. <em...@ge...>]

If folks don't have too many objections I would like to take a stab at
setting up synchmail to send emails about CVS activity to this list.

The last few days I have felt kind of odd seeing build results without
indication of what was changed.  (faq.htm and testing.htm)

More info can be found at:

http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1

Erik

[Junit-devel] Test2 interface

[Vladimir B. <vla...@bo...>]

Proposition for adding the getName() method to the Test interface:

* in the version 3.8
- create a Test2 that extends Test and adds getName()
- mark Test as deprecated
- TestSuite and TestCase now implement Test2
- _but_ all clients ui still work with the Test interface

... in the meantime users using 3.8 and having home-made classes that 
implement the Test interface update their code...

* in the version 3.9
- delete the Test.java file
- modify all clients to only recognize the Test2 interface

It's also possible to add a method to the Test interface directly but 
some users will have their tests broken.

The only requirement is to first use 3.8 before 3.9.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

[Junit-devel] JUnit Build 3.7.11 Successful

[<jjw...@ke...>]

View results here -> http://kenny.sir-toby.com:8080/junitBuild/BuildServlet?log200110241940L3.7.11

RE: [Junit-devel] TestRunListener (was File output)

[Kent B. <ken...@cs...>]

The basics of the approach are TestRunner and TestRunListener as interfaces.
My prefered method is to retrofit the current runners, split off as much of
BaseTestRunner as possible into a separate object, and then implement
the -listener command line option. But now, first things first.

Kent

Re: [Junit-devel] File output

[Vladimir B. <vla...@bo...>]

> I prefer Erich's approach, where you can attach multiple listeners to the
> same runner. One could log, another could display results textually, another
> graphically, another send email, another write a web page, another ding a
> bell. Since we want to do N things as feedback, no one of those things
> should have priority over the others.


No problem.  As this solution is more complex, this raises for me the 
question of the event-based architecture.  If such an architecture is to 
be implemented, I think the sooner is the better.

As I already have implemented these two features (logger - but not the 
graphical one - and event-based architecture) I'll be glad to share idea 
  with Erich.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

RE: [Junit-devel] File output

[Kent B. <ken...@cs...>]

I prefer Erich's approach, where you can attach multiple listeners to the
same runner. One could log, another could display results textually, another
graphically, another send email, another write a web page, another ding a
bell. Since we want to do N things as feedback, no one of those things
should have priority over the others.

Kent

[Junit-devel] File output

[Vladimir B. <vla...@bo...>]

Someone posted this morning a message because he/she wanted to write the 
result in a certain way.  And I think that 3.8 can have that really easily.

I have made a comparable thing in my prototype (writing the result into 
a file) but it's available for every runner.  The more I think about it, 
and the more I think that this is not the right thing to do.  Writing 
output file is a batch's job and it could be suffisant if only the 
textui has this functionality.

After running the tests, the textui opens a file a gives it to an object 
(interface Logger, let's say) which role is to format the TestResult 
into a stream and gives it back.  The TextUI then stores the result into 
the file (or dump it into the stdout if the file couldn't be opened) and 
closes the file.

Users would implement the Logger interface and by setting a property, 
the textui logger would know what king of Logger it has to use.

The role of the user is merely to retrieve the TestCases from the 
TestResult and write whatever he wants.

It's important to keep the '.' to show that something is running but 
separately writing the ouput file should not contain them.

What do you think about it?

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

RE: [Junit-devel] [PATCH] clean target for build.xml

[Erik M. <em...@ge...>]

I like it, just one thing.

			<classpath>
				<pathelement
location="${dist_dir}/test_release/junit${version}/junit.jar" />
				<pathelement location="${dist_dir}/test_release/junit${version}" />
			</classpath>

Is repeated three times, how do you feel about refids?

--- buildVBO.xml        Wed Oct 24 17:06:42 2001
+++ buildVBOP.xml       Wed Oct 24 19:39:08 2001
@@ -25,6 +25,12 @@

        <property name="versionfile"    value="junit/runner/Version.java" />

+
+       <path id="dist.path">
+               <pathelement
location="${dist_dir}/test_release/junit${version}/junit.jar" />
+               <pathelement
location="${dist_dir}/test_release/junit${version}" />
+       </path>
+
        <target name="init">
                <tstamp/>
                <mkdir dir="${api_dir}" />
@@ -179,30 +185,21 @@
        <target name="textui_release" depends="unzip_release">
                <java classname="junit.textui.TestRunner" fork="yes">
                        <arg value="junit.samples.AllTests" />
-                       <classpath>
-                               <pathelement
location="${dist_dir}/test_release/junit${version}/junit.jar" />
-                               <pathelement
location="${dist_dir}/test_release/junit${version}" />
-                       </classpath>
+                       <classpath refid="dist.path"/>
                </java>
        </target>

        <target name="awtui_release" depends="unzip_release">
                <java classname="junit.awtui.TestRunner" fork="yes">
                        <arg value="junit.samples.AllTests" />
-                       <classpath>
-                               <pathelement
location="${dist_dir}/test_release/junit${version}/junit.jar" />
-                               <pathelement
location="${dist_dir}/test_release/junit${version}" />
-                       </classpath>
+                       <classpath refid="dist.path"/>
                </java>
        </target>

        <target name="swingui_release" depends="unzip_release">
                <java classname="junit.swingui.TestRunner" fork="yes">
                        <arg value="junit.samples.AllTests" />
-                       <classpath>
-                               <pathelement
location="${dist_dir}/test_release/junit${version}/junit.jar" />
-                               <pathelement
location="${dist_dir}/test_release/junit${version}" />
-                       </classpath>
+                       <classpath refid="dist.path"/>
                </java>
        </target>



> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Wednesday, October 24, 2001 12:39 AM
> To: JUnit-Devel
> Subject: Re: [Junit-devel] [PATCH] clean target for build.xml
>
>
> New version (final) of the build.xml file.
>
> I have had some problems with the class loader and the test.jar file but
>   I won't explain as I have found a better solution.
>
> you can now test the classes from the 'build' directory using textui,
> swingui or awtui.  The javadoc documentation and the release's zip files
> are not generated.  But test.jar file is created and saved into the
> right directory (junit/tests).
>
> the task "publish" generates the javadoc documentation and the zip/jar
> files needed for the release
>
> to test the release, use textui_release, swingui_release, awtui_release.
>   As I didn't want to deal with the build directory anymore, I have
> decided to unzip the just created junitXY.zip into a fresh directory and
> call the junit.textui.TestRunner. (Swing + Awt) using only that directory.
>
> I really think that this is the cleanest way to test the release,
> because you are acting like a user downloading and installing JUnit for
> the first time (without the classpath problems...)
>
> The task "all" called by default, executes clean/build/publish and
> textui_release.
>
> Hope you like it, because I honestly don't know what I can change
> to it :-)
>
> -Vladimir
>
> --
> Vladimir Bossicard
> www.bossicard.com
>

RE: [Junit-devel] Re: Array assert equals

[Erik M. <em...@ge...>]

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Wednesday, October 24, 2001 1:36 AM
> To: JUnit-Devel
> Subject: [Junit-devel] Re: Array assert equals
>
>
> Here's my code.
>
>
> Before copy/pasting for every base type, I just want to have an ok.
>
> I have set the packages to junit.extensions and junit.tests.extensions.
>
> -Vladimir

I can tell it's your code.  For example:
	Object a[] = null;

should be formatted:
	Object a[]= null;

A search and replace of "]=" for "] =" should take care of that.

I see a lot of:
	Object a[] = null;

I would suggest initialize an nullArrayA, nullArrayB, etc. in setUp or
something
similar to that.

Also though personally I like seeing the separate classes imported, this is
not the style used by Kent and Erich.  JUnit uses import junit.framework.*;
as far as I can tell as soon as there are two classes imported from the same
package.  I was able to find three exceptions to this and in those three
cases
the number of classes was 2.

I think that ArrayAssert should be in junit.extensions not junit.tests.
extensions.

Looks like a good start.

Erik

RE: [Junit-devel] cruise.xml

[Erik M. <em...@ge...>]

> -----Original Message-----
> From: Vladimir Bossicard [mailto:vla...@bo...]
> Sent: Wednesday, October 24, 2001 11:37 AM
> To: Erik Meade; JUnit-Devel
> Subject: Re: [Junit-devel] cruise.xml
> 
> 
> > I think CruiseControl is important.  Since it is important I 
> think we should
> > have cruise.xml in CVS, after all that is where you put your important
> > files.
> > 
> > +1
> 
> 
> sorry, -1
> 
> I'm absolutely convinced that we need CruiseControl but I see too many 
> dependencies in the cruise.xml file (version number).
> 
> I will spend some time until this week-end to fix this and have a clean 
> solution.  I think it's really worth the extra hours.
> 
> So don't commit cruise.xml yet.
> 
> -Vladimir

cruise.xml has the same dependency on version number that build.xml does.

There are probably a few ways that cruise.xml can be preserved in CVS.
One way may be to add the cruise.xml targets to the build.xml.

Erik

Re: [Junit-devel] cruise.xml

[Jeffrey J. W. <jjw...@ke...>]

On Wed, 24 Oct 2001, Vladimir Bossicard wrote:

> > I think CruiseControl is important.  Since it is important I think we should
> > have cruise.xml in CVS, after all that is where you put your important
> > files.
> >
> > +1
>
>
> sorry, -1
>
> I'm absolutely convinced that we need CruiseControl but I see too many
> dependencies in the cruise.xml file (version number).
>
> I will spend some time until this week-end to fix this and have a clean
> solution.  I think it's really worth the extra hours.
>
> So don't commit cruise.xml yet.

	The other option is putting the CruiseControl specific targets in
build.xml and remove cruise.xml entirely. However, cruise.xml was created
originally so that we would avoid putting CruiseControl specific stuff in
the build.xml. There was some overlap between the two files since Ant
won't let properties declared in one build file be available to targets of
a seperate build file.

Re: [Junit-devel] cruise.xml

[Vladimir B. <vla...@bo...>]

> I think CruiseControl is important.  Since it is important I think we should
> have cruise.xml in CVS, after all that is where you put your important
> files.
> 
> +1


sorry, -1

I'm absolutely convinced that we need CruiseControl but I see too many 
dependencies in the cruise.xml file (version number).

I will spend some time until this week-end to fix this and have a clean 
solution.  I think it's really worth the extra hours.

So don't commit cruise.xml yet.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

[Junit-devel] cruise.xml

[Erik M. <em...@ge...>]

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Jeffrey J.
> Weston
>
> 	I'm not certain if there is a way for you to avoid breaking the
> build and still get the improved functionality out of build.xml that you
> are looking for. The updates to cruise.xml are simple. They just need to
> be timed to coordinate with the changes to build.xml. I suppose if
> cruise.xml was committed to CVS, you could commit both files at once. I
> don't know if we want CruiseControl specific files in the CVS repository
> though.

I think CruiseControl is important.  Since it is important I think we should
have cruise.xml in CVS, after all that is where you put your important
files.

+1

Erik

Re: [Junit-devel] [PATCH] clean target for build.xml

[Jeffrey J. W. <jjw...@ke...>]

On Wed, 24 Oct 2001, Vladimir Bossicard wrote:

> > 	I've been running CruiseControl on the JUnit project for a little
> > while now. It appears that the proposed build.xml may break the build
>
> how does it break the build and how can I fix that?  I don't know Cruise
> Control and don't know its requirements.

	See the attached cruise.xml file. This is the Ant build script I
use when building JUnit from CruiseControl. I needed my own clean target
to do a clean build, so I created one. CruiseControl calls the
"mastercleanbuild" target when doing a build. That in turns calls the
"dist" target on the JUnit build.xml. It looks like my clean target is
obsolete with the new build.xml. It also looks like the "dist" target no
longer exists.

	I'm not certain if there is a way for you to avoid breaking the
build and still get the improved functionality out of build.xml that you
are looking for. The updates to cruise.xml are simple. They just need to
be timed to coordinate with the changes to build.xml. I suppose if
cruise.xml was committed to CVS, you could commit both files at once. I
don't know if we want CruiseControl specific files in the CVS repository
though.

Re: [Junit-devel] [PATCH] clean target for build.xml

[Vladimir B. <vla...@bo...>]

> 	I've been running CruiseControl on the JUnit project for a little
> while now. It appears that the proposed build.xml may break the build


how does it break the build and how can I fix that?  I don't know Cruise 
Control and don't know its requirements.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

Re: [Junit-devel] [PATCH] clean target for build.xml

[Jeffrey J. W. <jjw...@ke...>]

Hello everyone,

	I've been running CruiseControl on the JUnit project for a little
while now. It appears that the proposed build.xml may break the build
until I can update how I run the build from CruiseControl. If you give me
some warning before its committed, I'll turn off CruiseControl so you
don't get spammed.

On Tue, 23 Oct 2001, Vladimir Bossicard wrote:

> New version (final) of the build.xml file.
<snip>

[Junit-devel] Re: Array assert equals

[Vladimir B. <vla...@bo...>]

Here's my code.


Before copy/pasting for every base type, I just want to have an ok.

I have set the packages to junit.extensions and junit.tests.extensions.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

Re: [Junit-devel] Bug #470324

[Vladimir B. <vla...@bo...>]

I propose to delete this panel and write the information directly into
the ProgressBar.  If you want an example, you can see the snapshot of my 
project.

Vote?

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

Re: [Junit-devel] [PATCH] clean target for build.xml

[Vladimir B. <vla...@bo...>]

New version (final) of the build.xml file.

I have had some problems with the class loader and the test.jar file but 
  I won't explain as I have found a better solution.

you can now test the classes from the 'build' directory using textui, 
swingui or awtui.  The javadoc documentation and the release's zip files 
are not generated.  But test.jar file is created and saved into the 
right directory (junit/tests).

the task "publish" generates the javadoc documentation and the zip/jar 
files needed for the release

to test the release, use textui_release, swingui_release, awtui_release. 
  As I didn't want to deal with the build directory anymore, I have 
decided to unzip the just created junitXY.zip into a fresh directory and 
call the junit.textui.TestRunner. (Swing + Awt) using only that directory.

I really think that this is the cleanest way to test the release, 
because you are acting like a user downloading and installing JUnit for 
the first time (without the classpath problems...)

The task "all" called by default, executes clean/build/publish and 
textui_release.

Hope you like it, because I honestly don't know what I can change to it :-)

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

[Junit-devel] JUnit Build 3.7.10 Successful

[<jjw...@ke...>]

View results here -> http://kenny.sir-toby.com:8080/junitBuild/BuildServlet?log200110232101L3.7.10

RE: [Junit-devel] [PATCH] close bug 471102 on swingui.TestRunner

[Kent B. <ken...@cs...>]

Test it and ship it. +1, unless Erich knows of some Swing constraints that
mitigate against it.

Kent

RE: [Junit-devel] [PATCH] clean target for build.xml

[Kent B. <ken...@cs...>]

Erich is in charge of the build.xml file (or at least I'm not) since I
haven't done enough with Ant not to make stupid mistakes. I'll stick with
making stupid CVS mistakes for the moment :-)

Kent