junit-devel — junit developers

[Junit-devel] [PATCH] fix for bug #469815

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

This patch should close out bug #469815
(http://sourceforge.net/tracker/index.php?func=detail&aid=469815&group_id=15
278&atid=115278)

I don't write tests this way so it is unfamiliar to me.  The code listed
below compiles and runs, but doesn't seem to do anything when the test fails
or passes.

Erik

Index: TestCase.java
===================================================================
RCS file: /cvsroot/junit/junit/junit/framework/TestCase.java,v
retrieving revision 1.5
diff -u -w -r1.5 TestCase.java
--- TestCase.java       2001/10/22 21:12:02     1.5
+++ TestCase.java       2001/10/24 02:26:05
@@ -41,8 +41,8 @@
  * In the static way you override the runTest method and define the method
to
  * be invoked. A convenient way to do so is with an anonymous inner class.
  * <pre>
- * Test test= new MathTest("add") {
- *        public void runTest() {
+ * TestCase test= new MathTest("add") {
+ *        protected void runTest() {
  *            testAdd();
  *        }
  * };
@@ -53,7 +53,7 @@
  * In this case the name of the test case has to correspond to the test
method
  * to be run.
  * <pre>
- * Test= new MathTest("testAdd");
+ * TestCase test= new MathTest("testAdd");
  * test.run();
  * </pre>
  * The tests to be run can be collected into a TestSuite. JUnit provides

[Junit-devel] Bug #470324

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

http://sourceforge.net/tracker/index.php?func=detail&aid=470324&group_id=152
78&atid=115278

I've included what I have started, but I can't get it to work.  I'm testing
it by copy-n-
pasting a bunch in junit.samples.AllTests.  If you delete test.jar or press
the stop
button the panel "shrinks" back and the numbers get cut off.

Erik

Index: CounterPanel.java
===================================================================
RCS file: /cvsroot/junit/junit/junit/swingui/CounterPanel.java,v
retrieving revision 1.2
diff -u -w -r1.2 CounterPanel.java
--- CounterPanel.java   2001/05/21 19:50:16     1.2
+++ CounterPanel.java   2001/10/24 01:26:50
@@ -19,16 +19,16 @@
                add(new JLabel("Runs:"));
                add(new JLabel("Errors:"));
                add(new JLabel("Failures: "));
-               fNumberOfErrors= createOutputField();
-               fNumberOfFailures= createOutputField();
-               fNumberOfRuns= createOutputField();
+               fNumberOfErrors= createOutputField(4);
+               fNumberOfFailures= createOutputField(4);
+               fNumberOfRuns= createOutputField(8);
                add(fNumberOfRuns);
                add(fNumberOfErrors);
                add(fNumberOfFailures);
        }

-       private JTextField createOutputField() {
-               JTextField field= new JTextField("0", 4);
+       private JTextField createOutputField(int fields) {
+               JTextField field= new JTextField("0", fields);
                field.setHorizontalAlignment(JTextField.LEFT);
                field.setFont(StatusLine.BOLD_FONT);
                field.setEditable(false);

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

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

This patch fixes bug number 471102
(http://sourceforge.net/tracker/index.php?func=detail&aid=471102&group_id=15
278&atid=115278)

Since the GridBagConstraints was HORIZONTAL clicking to the left of the
checkbox (under the run button) caused the reload checkbox to change state.
Changing the constraint to NONE doesn't change the appearance of the UI.

Votes?

Erik

Index: TestRunner.java
===================================================================
RCS file: /cvsroot/junit/junit/junit/swingui/TestRunner.java,v
retrieving revision 1.8
diff -u -w -r1.8 TestRunner.java
--- TestRunner.java     2001/10/21 02:30:18     1.8
+++ TestRunner.java     2001/10/24 00:41:55
@@ -407,7 +407,7 @@
                addGrid(panel, browseButton,    1, 1, 1,
GridBagConstraints.NONE,                    0.0, GridBagConstraints.WEST);
                addGrid(panel, fRun,            2, 1, 1,
GridBagConstraints.HORIZONTAL,         0.0, GridBagConstraints.CENTER);

-               addGrid(panel, fUseLoadingRunner,       0, 2, 3,
GridBagConstraints.HORIZONTAL, 1.0, GridBagConstraints.WEST);
+               addGrid(panel, fUseLoadingRunner,       0, 2, 3,
GridBagConstraints.NONE, 1.0, GridBagConstraints.WEST);
                addGrid(panel, new JSeparator(),        0, 3, 3,
GridBagConstraints.HORIZONTAL, 1.0, GridBagConstraints.WEST);

[Junit-devel] JUnit Build 3.7.9 Successful

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

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

RE: [Junit-devel] test.jar

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

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Tuesday, October 23, 2001 6:33 PM
> To: JUnit-Devel
> Cc: Erik Meade
> Subject: Re: [Junit-devel] test.jar
>
>
> > Running the UIs from sounds reasonable to me is there a
> particular reason
> > you want to do this?
>
>
> To speed up the compilation/test time.

Sounds like a good idea +1

> When I work on JUnit, I only call the "textui" target, which compiles
> and runs the tests.  I find it painfull to generate the javadoc and the
> jar files just to see if your modification is working.  I only run the
> whole stuff (javadoc and jar files) before sending a patch.
>
> I have written a separate build file that fits my needs but if I can
> share my thoughts.  And if I find it useful, other may find it useful too.
>
> maybe the following task will nicely solve the problem:
>    <target name="preparetests">
>       if the test.jar is not present
>           generate it into the build directory
>    </target>
>
> this task would be run before the ...Ui are started.  So you're
> independant whether you start from the jar files or the build directory.

It's not that the test.jar isn't being created (on gump) as you pointed out
it is.  It's not being picked up for some reason.  I'm thinking it may be
classpath releated.

Erik

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

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

> Sounds like a plan.  I have found that is often easier to make small
> changes then rewrite entire sections.  The result is often less "wasted"
> work by all parties.


I haven't changed much things, only separated targets (target for 
creation of jar, for generation of javadoc...), set variables in the 
beginning of the file (doc_dir, src_dir, build_dir...), compile the java 
files into the build directory and generate the correct zip file 
(junitX.Y) without having to create a subdirectory junitX.Y.

> This could be an opportunity to insure that one of the targets you want
> to get added does.  What is the harm in this patch being applied?


Erich (or Kent I don't have the mail in front of my eyes) agreed to have 
the java files build into the build directory.

Your patch would delete *.class files where they will no longer be 
generated.  No offense, I just start from the principle that my version 
will be checked in.  Kent should decide which build.xml file we're 
working with.  I'll send you the build.xml file this evening.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

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

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

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Tuesday, October 23, 2001 6:23 PM
> To: Erik Meade
> Cc: jun...@li...
> Subject: Re: [Junit-devel] [PATCH] clean target for build.xml
> 
> 
> Erik Meade wrote:
> 
> > I would like to have a target which leaves the cvs tree the way it was
> > before any targets have been run.  It saves me from blowing away my
> > dev directory and checking out from CVS over and over again.
> > 
> > Votes?
> 
> 
> -1
> 
> I have sent a build.xml that compiles the java files into a separate 
> directory (build).  This build file has already a <clean> target that 
> deletes the build and dist (for the jar/zip files) directories.
> 
> Hopefully this build.xml file will be soon checked-in, if Kent/Erich 
> don't see any problem with it.
> 
> I also want to add targets to start JUnit using classes in the build 
> directory and not the jar file.
> 
> -Vladimir

Sounds like a plan.  I have found that is often easier to make small
changes then rewrite entire sections.  The result is often less "wasted"
work by all parties.

This could be an opportunity to insure that one of the targets you want
to get added does.  What is the harm in this patch being applied?

Erik
 

Re: [Junit-devel] test.jar

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

> Running the UIs from sounds reasonable to me is there a particular reason
> you want to do this?


To speed up the compilation/test time.

When I work on JUnit, I only call the "textui" target, which compiles 
and runs the tests.  I find it painfull to generate the javadoc and the 
jar files just to see if your modification is working.  I only run the 
whole stuff (javadoc and jar files) before sending a patch.

I have written a separate build file that fits my needs but if I can 
share my thoughts.  And if I find it useful, other may find it useful too.

maybe the following task will nicely solve the problem:
   <target name="preparetests">
      if the test.jar is not present
          generate it into the build directory
   </target>

this task would be run before the ...Ui are started.  So you're 
independant whether you start from the jar files or the build directory.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

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

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

Erik Meade wrote:

> I would like to have a target which leaves the cvs tree the way it was
> before any targets have been run.  It saves me from blowing away my
> dev directory and checking out from CVS over and over again.
> 
> Votes?


-1

I have sent a build.xml that compiles the java files into a separate 
directory (build).  This build file has already a <clean> target that 
deletes the build and dist (for the jar/zip files) directories.

Hopefully this build.xml file will be soon checked-in, if Kent/Erich 
don't see any problem with it.

I also want to add targets to start JUnit using classes in the build 
directory and not the jar file.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

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

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

I would like to have a target which leaves the cvs tree the way it was
before any targets have been run.  It saves me from blowing away my
dev directory and checking out from CVS over and over again.

Votes?

Index: build.xml
===================================================================
RCS file: /cvsroot/junit/junit/build.xml,v
retrieving revision 1.5
diff -u -r1.5 build.xml
--- build.xml   2001/05/21 19:50:15     1.5
+++ build.xml   2001/10/23 22:55:51
@@ -8,6 +8,13 @@
                <property name="zipfile"  value="${dist}.zip" />
        </target>

+       <target name="clean" depends="init">
+               <delete quiet="yes" dir="${dist}"/>
+               <delete quiet="yes">
+                       <fileset dir="junit" includes="**/*.class"/>
+               </delete>
+       </target>
+
        <target name="versiontag" depends="init">
                <filter token="version" value="${version}" />
                <copy

RE: [Junit-devel] test.jar

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

Good eyes, I missed that.  I'm trying to figure out why the test.jar is
not being found under gump.  Works find for me.

At one point test.jar was in the test directory.  It was deleted.  You
can tell by looking in junit.tests's Attic.

I'm caught in the middle on the whole test.jar.  I would rather have the
test.jar generated by the build.xml so we are sure it gets done/updated.
But as Kent points out it would be nice to be able to have the all the
tests run when you import them into something like eclipse without
having to do more work.

Running the UIs from sounds reasonable to me is there a particular reason
you want to do this?

Erik

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Tuesday, October 23, 2001 5:08 PM
> To: Erik Meade
> Cc: Junit
> Subject: Re: [Junit-devel] test.jar
>
>
> > http://jakarta.apache.org/builds/gump/latest/junit.html
> >
> > Looks like the test.jar is not being generated on gump either.
>
>
>    [jar] Building jar: /home/rubys/jakarta/dist/junit/junit/tests/test.jar
>
> I have downloaded the tree this morning and test.jar was
> successfully generated.
>
>
> A solution could be to not generate the test.jar file but simply create
> one from scratch and put it into the tree.  Currently to test all the
> tests, you have to generate everything (javadoc, ...).  If it's OK when
> you're doing small modifications, it's a little bit annoying when having
> to run the tests several times per hour.
>
> I propose to modify the build.xml file :
> - enable to run the TextUI / SwingUI / AWTUi using the compiled classes
> and not the jar files (add new tasks for this)
> - store a 'test.jar' into the junit/tests folder
>
> vote?
>
> -Vladimir
>
> --
> Vladimir Bossicard
> www.bossicard.com
>
>
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel

Re: [Junit-devel] test.jar

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

> http://jakarta.apache.org/builds/gump/latest/junit.html
> 
> Looks like the test.jar is not being generated on gump either.


   [jar] Building jar: /home/rubys/jakarta/dist/junit/junit/tests/test.jar

I have downloaded the tree this morning and test.jar was successfully generated.


A solution could be to not generate the test.jar file but simply create 
one from scratch and put it into the tree.  Currently to test all the 
tests, you have to generate everything (javadoc, ...).  If it's OK when 
you're doing small modifications, it's a little bit annoying when having 
to run the tests several times per hour.

I propose to modify the build.xml file :
- enable to run the TextUI / SwingUI / AWTUi using the compiled classes 
and not the jar files (add new tasks for this)
- store a 'test.jar' into the junit/tests folder

vote?

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

RE: [Junit-devel] test.jar

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

http://jakarta.apache.org/builds/gump/latest/junit.html

Looks like the test.jar is not being generated on gump either.

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Kent Beck
> Sent: Sunday, October 21, 2001 1:42 PM
> To: Junit
> Subject: [Junit-devel] test.jar
>
>
> When I import the CVS tree, I don't get test.jar, so one of the self-tests
> fails. Is it possible to set CVS up so that I get test.jar (I noticed that
> Erich deleted it earlier), or do I have to run a build on my local machine
> to get it?
>
> Kent

RE: [Junit-devel] getName()

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

I have no idea how to do it from eclipse.  If you tell me the files and
version numbers you want I can do it.

Erik

> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Kent Beck
> Sent: Monday, October 22, 2001 7:04 PM
> To: Vladimir Bossicard
> Cc: jun...@li...
> Subject: RE: [Junit-devel] getName()
>
>
> You are absolutely right that the choice of formatting should be a job for
> the UI. Looking at the current getName, it looks like that does what you
> want already. Can you rewrite the test cases so it is exactly right?
>
> Kent
> P.S. How do I back out a CVS version? I'm using Eclipse, so I don't have a
> command line, which I couldn't use anyway without looking up the commands.
> Sigh... Spoiled by modern development environments again.

Re: [Junit-devel] FW: Yesterday's changes to junit and Gump

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

> We can see how changes in JUnit impact other open source projects via
> Gump.  I've requested that the results of Gump get sent here.


interesting.  It can really help.  But what happens when Ant is broken? :-)

 From http://jakarta.apache.org/builds/gump/latest/junit.html
- correct some errors with deprecated arguments
- is it absolutely necessary to generate the javadoc documentation? (if 
the user is compiling JUnit, he's smart enough to look at a target "api")
- Kent/Erich: what about committer rights to the tree?  I thing it could 
speed up the process.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

[Junit-devel] FW: Yesterday's changes to junit and Gump

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

We can see how changes in JUnit impact other open source projects via
Gump.  I've requested that the results of Gump get sent here.

Forwarded from dicussion:

-----Original Message-----
From: nobody [mailto:no...@so...]On Behalf Of
no...@so...
Sent: Monday, October 22, 2001 7:11 AM
To: no...@so...
Subject: [junit - Open Discussion] Yesterday's changes to junit and Gump



Read and respond to this message at:
http://sourceforge.net/forum/message.php?msg_id=253518
By: rubys

I'd like your help.

I've been doing a little experiment in testing on a rather large scale.  For
example, the difference in failures between

http://jakarta.apache.org/builds/gump/2001-10-22/
and
http://jakarta.apache.org/builds/gump/2001-10-21/

appear to all be attributable to the following changes:
http://jakarta.apache.org/builds/gump/2001-10-22/cvs_junit.html

The complete set of builds are executed daily.  Additional, interim builds
are
done every six hours, with those results posted at
http://nagoya.apache.org/~rubys/gump/.

Overall information on gump can be found at http://jakarta.apache.org/gump/

"keep the bar green to keep the code clean"  ;-)

RE: [Junit-devel] JUnit Build 3.7.8 Successful

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

The tests are being executed, they are not being reported.  This is because
the tests are launched via java and not the junit task.  I researched why
when
we first setup cruisecontrol, but don't remember the exact reason.  We need
a
TestRunner that outputs xml the same way the ant JUnit task does.

Erik


> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Tuesday, October 23, 2001 1:48 AM
> To: jun...@li...
> Subject: Re: [Junit-devel] JUnit Build 3.7.8 Successful
>
>
> > View results here ->
> http://kenny.sir-toby.com:8080/junitBuild/BuildServlet?log20011022
> 1402L3.7.8
>
>
> How to execute the tests after each build?
>
> -Vladimir
>
> --
> Vladimir Bossicard
> www.bossicard.com
>
>
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel

Re: [Junit-devel] JUnit Build 3.7.8 Successful

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

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


How to execute the tests after each build?

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

RE: [Junit-devel] getName()

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

You are absolutely right that the choice of formatting should be a job for
the UI. Looking at the current getName, it looks like that does what you
want already. Can you rewrite the test cases so it is exactly right?

Kent
P.S. How do I back out a CVS version? I'm using Eclipse, so I don't have a
command line, which I couldn't use anyway without looking up the commands.
Sigh... Spoiled by modern development environments again.

[Junit-devel] JUnit Build 3.7.8 Successful

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

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

Re: [Junit-devel] getName()

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

Thank Kent for checking in.  I like how the work is getting done.
I have just checked the code and have some comments:

- TestCase:
	public String getDisplayName() {
	    return getName()+"("+getClass().getName()+")";
	}
   1. if a user has created a TestCase with a certain name I think he 
expects that TestCase to be displayed with the name he specified
   2. the generated name can be quite long.  The user knows where to 
locate the TestCase with a specific name
   3. the ui should be free to decide if it wants to display the 
'getDisplayName' result with ou without the getClass()...  We will keep 
the method thin and avoid some bad code like 
getDisplayName().substring(getDisplayName().getPositionOf(" ")...

- TestSuite:
	 public String getDisplayName() {
	 
	if (getName() == null)
	 
		return "Anonymous suite";
	 
	else
	 
		return getName();
	 }
   1. the UI should be responsible to deal with not explicitely 
specified names.  If the suite is 'anonymous', maybe a client want to 
display getClass().getName() and not "anonymous suite"

OK you see my point... getDisplayName() only returns getName() -> do we 
need getDisplayName()...

I always think that the UI should decide how it wants to display the 
information and not the framework.  But it's maybe only me.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com

RE: [Junit-devel] getName()

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

It seems to me getName() should remain the same as it is now, but
getDisplayName() should be added to Test. I've checked in a version that
implements getDisplayName in this way. I'm sorry if this is the wrong
etiquette--I can't figure out how to just generate diffs to send to
everyone. If folks don't like this, we can roll it back.

Kent

RE: [Junit-devel] getName()

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

The angle I (and I believe Kent)was coming from is that right now, getName
is used to identify which test to run for rerun in swingui.TestRunner and
awtui.TestRunner.  Both of which are very similar, the top one (awtui)
could be refactored to look like the bottom one BTW (code below).  (votes
for refactoring the awtui rerun to call reRunTest as in swingui?)

So back to getName()... Here getName uses the name of the Test to get the
test given the test's classname.  Erich has proposed a TestRunner interface
that uses java types and primitives (Strings and longs) as opposed to some
junit class. so that classes that implement TestRunner don't have to use
serialization of objects for remote calls.

The first TestRunner interface had one string to build your test in rerun.
The second passes in the two strings, classname and testname.  So I think
using the second interface answers our questions on getName(), keep it the
same.  Kent?

Erik

======= rerun in awtui.TestRunner
	public void rerun() {
		int index= fFailureList.getSelectedIndex();
		if (index == -1)
			return;

		Test test= (Test)fFailedTests.elementAt(index);
		if (!(test instanceof TestCase)) {
			showInfo("Could not reload "+ test.toString());
			return;
		}
		Test reloadedTest= null;
		try {
			Class reloadedTestClass= getLoader().reload(test.getClass());
			Class[] classArgs= { String.class };
			Constructor constructor= reloadedTestClass.getConstructor(classArgs);
			Object[] args= new Object[]{((TestCase)test).getName()};
			reloadedTest=(Test)constructor.newInstance(args);
		} catch(Exception e) {
			showInfo("Could not reload "+ test.toString());
			return;
		}
		TestResult result= new TestResult();
		reloadedTest.run(result);

		String message= reloadedTest.toString();
		if(result.wasSuccessful())
			showInfo(message+" was successful");
		else if (result.errorCount() == 1)
			showStatus(message+" had an error");
		else
			showStatus(message+" had a failure");
	}


======= rerun in swingui.TestRunner

	private void rerun() {
		TestRunView view=
(TestRunView)fTestRunViews.elementAt(fTestViewTab.getSelectedIndex());
		Test rerunTest= view.getSelectedTest();
		if (rerunTest != null)
			rerunTest(rerunTest);
	}

	private void rerunTest(Test test) {
		if (!(test instanceof TestCase)) {
			showInfo("Could not reload "+ test.toString());
			return;
		}
		Test reloadedTest= null;
		try {
			Class reloadedTestClass= getLoader().reload(test.getClass());
			Class[] classArgs= { String.class };
			Object[] args= new Object[]{((TestCase)test).getName()};
			Constructor constructor= reloadedTestClass.getConstructor(classArgs);
			reloadedTest=(Test)constructor.newInstance(args);
		} catch(Exception e) {
			showInfo("Could not reload "+ test.toString());
			return;
		}
		TestResult result= new TestResult();
		reloadedTest.run(result);

		String message= reloadedTest.toString();
		if(result.wasSuccessful())
			showInfo(message+" was successful");
		else if (result.errorCount() == 1)
			showStatus(message+" had an error");
		else
			showStatus(message+" had a failure");
	}


> -----Original Message-----
> From: jun...@li...
> [mailto:jun...@li...]On Behalf Of Vladimir
> Bossicard
> Sent: Sunday, October 21, 2001 3:11 PM
> To: jun...@li...
> Subject: Re: [Junit-devel] getName()
>
>
> >
> >
> >It seems like we want a method that means "get the displayable
> name of this
> >implementor of Test".
> >
> Originally I wanted a method that meant "get the name the
> TestCase/TestSuite was created with".  As a TestSuite can be created
> without a name, it is up to the calling application to handle this.
>
> If a user don't create a TestSuite with a name, he should not expect the
> tree (for example) to display anything special.  Maybe the TestSuite's
> classname or "Name not provided".  If he does want a specific name, he
> can just specify it!
>
> -Vladimir
>
> --
> Vladimir Bossicard
> www.bossicard.com
>
>
> _______________________________________________
> Junit-devel mailing list
> Jun...@li...
> https://lists.sourceforge.net/lists/listinfo/junit-devel

RE: [Junit-devel] RE: Programmieren sind Schweinen

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

I'll send the code when I've had a chance to change it in Erich's suggested
direction. TestResult doesn't seem the right place to broadcast all
messages, at least not yet. However, what is now the BaseTestRunner is
likely to get thinner and thinner. I can imagine we will want to merge it
with TestResult, but only after the diet.

Kent

Re: [Junit-devel] RE: Programmieren sind Schweinen

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

> Okay, so we'll base the TestRunListener on TestEvents. I noticed, Erich,
> that your remote runner had it done both ways.


Where can I have a look at some code?  What I have done is the 
TestResult communicating with TestEvent and I'm interested in seeing 
your design.

I personally find my solution (the TestResult doing all the dispatching 
work, for UI and non-UI listeners) quite heavy.

-Vladimir

-- 
Vladimir Bossicard
www.bossicard.com