J. B. Rainsberger wrote:
> Kent Beck wrote:
>
>
>> Apparently I haven't stated this strong enough in the past. You should
>> assume that each test method will be run with a fresh test method in JUnit.
>> This has been part of the architecture from the beginning and I don't see
>> any reason to change it. The principle behind this choice is that tests
>> should be order-independent. Running with separate instances supports
>> independence.
>>
>
> That's fine. As I think about it, there's still another reason not to
> initialize objects in the constructor: test instance creation happens
> well before the test runs, so if too much initialization happens in the
> constructor, one might run out of memory before running any tests.

Just to further clarify, this is JUnit 3 behavior.  In JUnit 4.1, test
instance creation happens right before test execution, so this
particular reason to favor setUp is no longer the case.  As Kent has
noticed, this is not yet an API guarantee for 4.x, however.

Share and enjoy,

     David Saff

On 7/20/06, Cédric Beust ♔ <cbeust@...> wrote:
> Hi J.B.,
>
> On 7/18/06, J. B. Rainsberger <jbrains@...> wrote:
> >
> > Andreas Guther wrote:
> >
> > > The fact that setup() and the constructor are equivalent as Cedric
> > > pointed out is always confusing and something everyone should be aware
> > > of using JUnit.
> >
> > They are not equivalent! It is an accident of implementation that
> > initializing fixture objects in the constructor behaves the same way as
> > the setUp() method does.
>
>
> Can you clarify this?  If they behave exactly the same way (in JUnit3 at
> least), how are they not equivalent?
>

I am almost certain that we had this exact same discussion in this
exact same forum with the exact same people about a year ago ;-)  I
even posted the same example - at least one that is very similar to
this ...

import junit.framework.TestCase;

public class InterDependentTest extends TestCase {
   private static int externalStateInitializedInConstructor;
   private static int externalStateInitializedInSetup;

   public InterDependentTest() {
     externalStateInitializedInConstructor = 0;
   }

   protected void setUp() throws Exception {
     externalStateInitializedInSetup = 0;
   }

   public void testConstructorOne() throws Exception {
     assertEquals(0, externalStateInitializedInConstructor++);
   }

   public void testConstructorTwo() throws Exception {
     assertEquals(0, externalStateInitializedInConstructor++);
   }

   public void testSetupOne() throws Exception {
     assertEquals(0, externalStateInitializedInSetup++);
   }

   public void testSetupTwo() throws Exception {
     assertEquals(0, externalStateInitializedInSetup++);
   }

}

In my IDE, in JUnit 3.8, all the tests pass except testConstructorTwo.
If you have external static state that needs to reset between tests,
it must be reset in setup() because setup() is called between every
test. Constructors are not.

The algorithm (in JUnit 3.8, in most runners) is approximately :

for each test
   construct Test
end

for each test
   call setup
   run test
   call tear down
end

Kevin

Hi Kent,

Thanks for your suggestion of extending an existing TestRunner. However,
that's a bit of a non-starter for a single codebase component as our QA
run uses the TextUI TestRunner and our developers tend to use Eclipse's
RemoteTestRunner - I'd be up against some pretty stiff competition.

As TestSuite#isTestMethod is private I'm unable to modify the naming
convention that JUnit searches for, so I've plumped for extending
TestSuite#runTest(Test,TestResult). If I refactor to an improved
solution, I'll post my findings!

Thanks,

Steve.

--
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/

Kent Beck wrote:
> Steve,
>
> To run just certain tests, you could write your own test runner. As
> mentioned in the JUnit Pocket Guide, writing runners is a surprising rare
> but useful technique. A simple way to do this is to pass your own TestResult
> as a parameter to you test suite:
>
> ...Test suite= ...
> TestResult result= new TestResult() {
>   protected void run(final TestCase test) {
>     // do whatever you want to do here
>   }
> };
> suite.run(result);
> return result;
>
> I hope this helps.
>
> Cheers,
>
> Kent Beck
> Three Rivers Institute
>
>
>   _____
>
> From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
> Stephen Smith
> Sent: Monday, July 31, 2006 10:32 AM
> To: junit@yahoogroups.com
> Subject: Re: [junit] Re: Filtering by method in JUnit 3.8-style tests
>
>
>
> Setting aside JUnit 4.x temporarily, is there any way using the JUnit
> 3.8.x API I can filter out particular test methods based upon a set of
> criteria, without resorting to implementing a suite() method on each
> individual TestCase?
>
> Thanks,
>
> Steve.
> --
> Stephen Smith, MEng (Wales).
> http://www.stephen- <http://www.stephen-smith.co.uk/> smith.co.uk/
>
> Michael Schechter wrote:
>> That's odd - it works just fine for me. However, trying to filter on
>> more than one method doesn't seem to be intuitively obvious, and
>> nothing really seems to work.
>>
>> The code I use to get one test to run is as follows (it's from the
>> test class's main() method):
>> JUnitCore core = new JUnitCore();
>> Request testRequest = Request.method(aTestClass, someArguments[0]);
>> core.run(testRequest);
>>
>> I have no idea how to extend this model to being able to specify
>> multiple methods, however.
>>
>> In addition, I really hope that someone starts documenting all of the
>> nifty new features in JUnit 4.x - the current level is somewhat
>> (frustratingly) incomplete. The basic features have been covered by a
>> number of writers - the more complex, such as this issue, still seem
>> to be missing.
>>
>> I think JUnit has the potential to become even more popular with a
>> clearer examination of the framework on which it is built. There seems
>> to be a great deal of power and flexibility available - it's just
>> really unclear as to how to get at it.
>>
>> Thanks in advance!
>>
>> Michael Schechter
>>
>> --- In junit@yahoogroups. <mailto:junit%40yahoogroups.com> com, David Saff
> <saff@...> wrote:
>>> Shannon,
>>>
>>> You are right--this doesn't currently work in JUnit 4.1. Could you
>> open
>>> a tracker issue on the sourceforge page, and we'll see if this can be
>>> remedied in a future version? Thanks,
>>>
>>> David Saff
>>>
>>> Shannon wrote:
>>>> Greetings,
>>>>
>>>> I'm trying to filter a JUnit 3.8x test case class using the 4.1
>>>> runner, so that only one of the test methods in the class is run and
>>>> the others are ignored. I create and run the test like this:
>>>>
>>>> Request r = Request.method(OldStyleTestCase.class, "testSomeMethod");
>>>> jcore.run(r);
>>>>
>>>> The outcome is that all test methods are run, not just the one test
>>>> method I specified. I also tried using a custom filter, but the filter
>>>> never gets called because the runner for this class is
>>>> org.junit.internal.runners.OldTestClassRunner which does not implement
>>>> Filter.
>>>>
>>>> Do I need to write my own runner to get this to work? Is there another
>>>> work around?
>>>>
>>>> Thanks for any help.
>>>>
>>>> /Shannon
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Stephen Smith wrote:

> Setting aside JUnit 4.x temporarily, is there any way using the JUnit
> 3.8.x API I can filter out particular test methods based upon a set of
> criteria, without resorting to implementing a suite() method on each
> individual TestCase?

DirectorySuiteBuilder and RecursiveTestSuite each allow you to do it.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.info
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

Anna,

> The application is a kind of specialized graphic editor with a typical
> MDI design. Its core is an object, say APP, static reference of which
> is kept in the main class (much like in singleton, but the
> constructor's not private; for the above stated reasons I don't want
> to discuss this detail).
>
> *snip*
>
> And what's what started to give me trouble recently. It is possible to
> initialize this APP object, loading GUI modules or not. To be honest,
> using it without UI is a workaround of mine, which I implemented to be
> somewhat closer to unit testing, although my tasks are actually
> regular regression tests, examining whole big chunks of
> functionality... So in a part of my tests that don't need the
> graphical modules, I simply don't load them. However, I've recently
> been trying out some other type of tests that operate on a
> full-fledged application, which needs loading the UI. And that's where
> the problem begins - trying to load those modules, having used the
> application without them in previous tests, is in the application, as
> it currently is, impossible (and don't think that anyone will take
> grumbling of a humble tester into consideration).
>
> So the question to you guys is as follows: should I give up hope that
> my job has anything to do with unit testing, and allow dosens of funny
> windows to jump here and fro while basic functionality is being
> checked or rather do you see any other possibility to solve my problem
> that I, humble rookie, overlooked?

If the app class has a non-private constructor, then your tests don't
need to instantiate it as a singleton, right? And you also modifed the
app class so that you can suppress the loading of the UI modules. What,
then, is impossible about having some tests instantiate the app without
the UI bits, and other tests that do?

Actually, a clarification - I am using JUnit 4.1 tests in this
fashion. We've completely converted - sorry for misleading the topic.

However, this leaves me somewhat further afield with specifying more
than one test method to be run using the JUnit 4 APIs. I've looked
through the classes, even regenerating the Javadoc, and can't find
anything. I'm very confused (and a little frustrated) because the
classes or methods I want to use are either undocumented (no Javadoc)
or marked for internal use only.

Any suggestions?

--- In junit@yahoogroups.com, "Michael Schechter" <bard@...> wrote:
>
> That's odd - it works just fine for me. However, trying to filter on
> more than one method doesn't seem to be intuitively obvious, and
> nothing really seems to work.
>
> The code I use to get one test to run is as follows (it's from the
> test class's main() method):
>     JUnitCore core = new JUnitCore();
>     Request testRequest = Request.method(aTestClass, someArguments[0]);
>     core.run(testRequest);
>
> I have no idea how to extend this model to being able to specify
> multiple methods, however.
>
> In addition, I really hope that someone starts documenting all of the
> nifty new features in JUnit 4.x - the current level is somewhat
> (frustratingly) incomplete. The basic features have been covered by a
> number of writers - the more complex, such as this issue, still seem
> to be missing.
>
> I think JUnit has the potential to become even more popular with a
> clearer examination of the framework on which it is built. There seems
> to be a great deal of power and flexibility available - it's just
> really unclear as to how to get at it.
>
> Thanks in advance!
>
> Michael Schechter
>
> --- In junit@yahoogroups.com, David Saff <saff@> wrote:
> >
> > Shannon,
> >
> > You are right--this doesn't currently work in JUnit 4.1.  Could you
> open
> > a tracker issue on the sourceforge page, and we'll see if this can be
> > remedied in a future version?  Thanks,
> >
> >     David Saff
> >
> > Shannon wrote:
> > > Greetings,
> > >
> > > I'm trying to filter a JUnit 3.8x test case class using the 4.1
> > > runner, so that only one of the test methods in the class is run and
> > > the others are ignored. I create and run the test like this:
> > >
> > > Request r = Request.method(OldStyleTestCase.class,
"testSomeMethod");
> > > jcore.run(r);
> > >
> > > The outcome is that all test methods are run, not just the one test
> > > method I specified. I also tried using a custom filter, but the
filter
> > > never gets called because the runner for this class is
> > > org.junit.internal.runners.OldTestClassRunner which does not
implement
> > > Filter.
> > >
> > > Do I need to write my own runner to get this to work? Is there
another
> > > work around?
> > >
> > > Thanks for any help.
> > >
> > > /Shannon
>

I have the exact same problem - i.e. trying to use MockRunner in
Eclipse. This is compounded by the fact that I am using the continuous
test plugin which executes these tests automatically using the
built-in Eclipse junit mechanism and keeps telling me that my tests
have failed. So it isn't an option for me to run the tests some other way.

Joe thanks for the recipe.  I avoided taking that route before since
<junit> and <junitreport> were such an improvement over what I had
originally.  However (I think) I have run up against a limitation of
the <junit> task which makes me revisit this solution.  The <junit>
task isn't working for me because it won't allow you to control how
much exception stack trace information is kept for each failure.  I
only want to see the first line or two (the only really useful info in
the exception stack), but I want to limit the amount of exceptions
that are reported because I appear to be running out of memory when I
run a full test suite of over 80 tests.  This never happened before I
started using Ant/<junit>/<junitreport>, and my assumption is that the
exception stacks for each failure are being kept in memory by the
<junit> task, which is expecting to write all of the info to XML once
the suite completes.  Unfortunately after so many failures the
exception stack info being held in memory is so much that the program
crashes with an out-of-memory error.  Is my assumption correct?  Will
the TestListener approach help me?


--James




--- In junit@yahoogroups.com, "J. B. Rainsberger" <jbrains@...> wrote:
>
> james_adams wrote:
>
> > I have inherited some code which runs a suite of JUnit test cases (via
> > junit.textui.TestRunner.doRun(mySuite)) and outputs the results of the
> > test case either as "." for a success, or ".F" for a failure, followed
> > by the errors and a summary of the run results. So if I have three
> > test cases in the suite, and the first and third test cases succeed,
> > then the output file looks like "..F." followed by the errors and a
> > summary of how many successes/failures. There are about 80 test cases
> > in the suite I'm working with, and it is very time consuming and error
> > prone to try to figure out which tests succeeded and which ones failed
> > from a long list of dots and dot-F's. What I would like instead is to
> > have the report look something like this:
> >
> > test-01-01: success
> > test-01-02: failure
> > test-02-01: success
> >
> > <errors>
> >
> > <summary>
> >
> > I have looked at the JavaDoc for junit.textui.TestRunner and there is
> > no way to specify how the final report comes out, more specifically no
> > way to tell it to print the name of the test case and the result
> > rather than either "." for success or ".F" for failures.
> >
> > Can anyone advise me how I can modify this behavior? Am I stuck and
> > just need to write a parser to convert the "..F." to a meaningful
> > report as to which tests succeeded or failed (as in the above
example)?
>
> You're not stuck writing a parser. Instead, you can write a
TestListener
> that generates the kind of report you'd like to generate. I've taken
the
> liberty of sending you (privately) a recipe from _JUnit Recipes_ on the
> topic. I have found it easiest to use the JUnit-addons test runner and
> plug in whatever test listeners I want.
>
> Take care.
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.info
> Your guide to software craftsmanship
> JUnit Recipes: Practical Methods for Programmer Testing
> 2005 Gordon Pask Award for contribution Agile Software Practice
>

Hello,
I'm trying to launch some JUnit TestCase referenced in a JUnit TestSuite
with this code :

AllTests testSuite = new AllTests();
TestRunner.run(testSuite.getClass());

that code produce this error :

There was 1 failure:
1)
warning(junit.framework.TestSuite$1)junit.framework.AssertionFailedError:
No tests found in diderot.ana.soc.rules.services.test.AllTests
	 at
diderot.ana.soc.rules.services.test.actions.JUnitLauncher.run(JUnitLauncher.java\
:52)
	 at
org.eclipse.ui.internal.PluginAction.runWithEvent(PluginAction.java:254)
	 at
org.eclipse.ui.internal.WWinPluginAction.runWithEvent(WWinPluginAction.java:229)
	 at
org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionCont\
ributionItem.java:539)
	 at
org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.\
java:488)
	 at
org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContribution\
Item.java:400)
	 at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
	 at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
	 at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3164)
	 at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2840)
	 at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
	 at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
	 at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
	 at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	 at diderot.ana.soc.didrcp.Application.run(Application.java:30)
	 at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java\
:78)
	 at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Ecli\
pseAppLauncher.java:92)
	 at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLau\
ncher.java:68)
	 at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
	 at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
	 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav\
a:25)
	 at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
	 at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
	 at org.eclipse.core.launcher.Main.run(Main.java:977)
	 at org.eclipse.core.launcher.Main.main(Main.java:952)


notes :
-------
- AllTests class extends TestSuite
- This code is runnig under Eclipse 3.2 in a RCP application
- Out of the RCP application it run well (with "Execute as JUnit plugin")

Does anyone already had this kind of problem ? and if yes how to solve
it ?
Thanks for any help...

I've written JUnit cases for over 1 month.

I have to say it's fun to do the implement coding. But it's suffering to
write JUnit cases. Because:
1. I need to know the correct result from the other way around and sometimes
it's hard to find another way.
2. Database and JSP pages are difficult to JUnit test.
3. Mock objects brings more than double efforts during the whole develop
process.
4. Exception situation is not so easy to make as JUnit claims.

3 friends in 3 different companies (small size and middle size company)
complain JUnit as:
1. They planned JUnit testing firstly and they cannot keep it going. TIME
reason?
2. It consumes a lot of time but hard to find big problems. JUnit does find
small problems as we expected.
3. JUnit testing is not effcient enough.
4. Best JUnit tester is the senior software developer. But senior guys hate
to write test cases.
5. For small company, it's really hard to choose between JUnit+develop and
develop+functional testing.

Is there anyone who is successful in deploying JUnit during develop as:
JUnit + code + JUnit + code + System Testing?
--
View this message in context:
http://www.nabble.com/Are-you-really-using-JUnit-during-your-development--tf2039\
307.html#a5612073
Sent from the JUnit - User forum at Nabble.com.

On 8/2/06, Jean <2004jing.lei@...> wrote:

> Is there anyone who is successful in deploying JUnit during develop as:
> JUnit + code + JUnit + code + System Testing?
>




Yes.  Every day.

You're right - some things are easier to unit test then others.  I'm not
perfect, and I'm still learning.  But, I'm doing it (and have been for six
years now).

Cheers!
Carl





--
http://genomescampaigns.blogspot.com


[Non-text portions of this message have been removed]

On 8/2/06, Carl Hume <carl.hume@...> wrote:
>
> On 8/2/06, Jean <2004jing.lei@...> wrote:
>
> > Is there anyone who is successful in deploying JUnit during develop as:
> > JUnit + code + JUnit + code + System Testing?
> >
>
> Yes.  Every day.
>
> You're right - some things are easier to unit test then others.  I'm not
> perfect, and I'm still learning.  But, I'm doing it (and have been for six
> years now).


Like Carl for over six years using JUnit/NUnit (for .NET) work. Its hard
work at first but gets easier with time. J.B. Rainsberger's book Junit
recipes (
http://www.amazon.com/gp/product/1932394230/104-6174901-2999136?v=glance&n=28315\
5)
is a great to get up to speed quickly. However nothing replaces practice.
Try, fail, learn, try again.

Cheers
Mark Levison


[Non-text portions of this message have been removed]

That's got me beat. I've only been using it regularly for four years.
[Hangs head in shame!]

As a technical lead and now a mentor, I don't cut code every day
(meetings ... pah!), but when I do cut code, I test most everything I
write.

Over the past four years of writing tests, the time taken to write
individual tests goes down, and the reliability of my code goes up.
Sounds like a good long term trend to me. :-)

Simon
--
www.simonpeter.org


On 8/2/06, Carl Hume <carl.hume@...> wrote:
> On 8/2/06, Jean <2004jing.lei@...> wrote:
>
> > Is there anyone who is successful in deploying JUnit during develop as:
> > JUnit + code + JUnit + code + System Testing?
> >
>
>
>
>
> Yes.  Every day.
>
> You're right - some things are easier to unit test then others.  I'm not
> perfect, and I'm still learning.  But, I'm doing it (and have been for six
> years now).
>
> Cheers!
> Carl
>

On 8/2/06, Jean <2004jing.lei@...> wrote:
>
>
>
> I have to say it's fun to do the implement coding. But it's suffering to
> write JUnit cases.


Don't feel bad, your situation is pretty common in my experience.

The important thing is to realize that tests are important and always do
your best to make them part of your development process.  We all know that
in the real world, sometimes, other tasks take precedence.  Just exercise
your judgment, put testing in the backseat when the circumstances warrant it
(tight deadline, angry customer, etc...) but always remember to get back to
them and pay your technical debt whenever you get a chance.

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

On 8/2/06, Jean <2004jing.lei@...> wrote:
>
> Is there anyone who is successful in deploying JUnit during develop as:
> JUnit + code + JUnit + code + System Testing?
> --

It's tempting to start a new thread asking if there is anyone NOT
using junit during development ;-) ... but that probably wouldn't help
you much.

If there is a single big secret to being successful with JUnit it is
virtuous circle of :

   testability -> more tests -> more testability -> more tests

Three or four times around this loop and you will probably also wonder
how you ever managed without unit tests.

Many newcomers to automated unit tests expect to be able to test their
code with no changes or are reluctant to make changes /just/ to make
it easier to test... they often give up on the whole deal because they
find it too hard.

I blogged about this a while back :
http://www.developertesting.com/archives/month200401/20040116-WhyIsSoftwareSoHar\
dToTest.html

Kevin

On 8/2/06, Kevin Lawrence <kev.lawrence@...> wrote:
>
>
> It's tempting to start a new thread asking if there is anyone NOT
> using junit during development ;-)


Not everybody uses JUnit, you know...

Three or four times around this loop and you will probably also wonder
> how you ever managed without unit tests.


The problem is usually more along the lines of "How can I manage with unit
tests?".  As the original poster pointed out, the reality depicted in books
about testing is very different from the real world, and practical advice
for that is fairly scarce (yes, I read Michael Feather's book).

Many newcomers to automated unit tests expect to be able to test their
> code with no changes or are reluctant to make changes /just/ to make
> it easier to test... they often give up on the whole deal because they
> find it too hard.


That's one reason, there are plenty of others, such as "We're approaching a
deadline and I have to add this feature for our customer, so I'll do that
instead of adding a test".

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

Cédric Beust ♔ wrote:
>
> On 8/2/06, Jean <2004jing.lei@...
> <mailto:2004jing.lei%40gmail.com>> wrote:
>  >
>  > I have to say it's fun to do the implement coding. But it's suffering to
>  > write JUnit cases.
>
> Don't feel bad, your situation is pretty common in my experience.
>
> The important thing is to realize that tests are important and always do
> your best to make them part of your development process. We all know that
> in the real world, sometimes, other tasks take precedence. Just exercise
> your judgment, put testing in the backseat when the circumstances warrant it
> (tight deadline, angry customer, etc...) but always remember to get back to
> them and pay your technical debt whenever you get a chance.

I'd have to admit that I find coding the /tests/ quite interesting and
challenging in their own right. Here are just some of the things that
testing has introduced me to, which I may never have otherwise come across:

* java.lang.reflect.Proxy - awesomely powerful. 99% of what you need it
for is covered by mock objects, but for that remaining 1%, it's
indispensible
* Jetty (www.mortbay.org) - I've got network utility tests that stand up
an embedded Web server to serve content. One example is a wrapper around
java.net.URL that verifies content types (e.g. MIME types). Its test
pretty much requires a live Web server to vend the appropriate content.
* java.lang.AccessibleObject.setAccessible(boolean) - the subject of a
recent thread here
* code correctness tools (PMD, findbugs, checkstyle) - technically not
limited to testing, but that's how I got exposed to it
* dependency injection
* and many more

James,

You problably run out of memory during the junitreport task.
If that's the case, and if you can do with a plain text report,
follow these steps:

1: In your ant's junit target, replace the xml formatter by a plain formatter.
2: Remove the junitreport target.

Regards, Jan


   ----- Original Message -----
   From:   james_adams
   To: junit@yahoogroups.com
   Sent: Wednesday, August 02, 2006 2:51   AM
   Subject: [junit] Re: How to modify JUnit   output to something more readable?



Joe thanks for the recipe. I avoided taking that route before   since
<junit> and <junitreport> were such an improvement over   what I had
originally. However (I think) I have run up against a limitation   of
the <junit> task which makes me revisit this solution. The   <junit>
task isn't working for me because it won't allow you to   control how
much exception stack trace information is kept for each   failure. I
only want to see the first line or two (the only really useful   info in
the exception stack), but I want to limit the amount of   exceptions
that are reported because I appear to be running out of memory   when I
run a full test suite of over 80 tests. This never happened before   I
started using Ant/<junit>/<junitreport>, and my   assumption is that the
exception stacks for each failure are being kept in   memory by the
<junit> task, which is expecting to write all of the   info to XML once
the suite completes. Unfortunately after so many failures   the
exception stack info being held in memory is so much that the   program
crashes with an out-of-memory error. Is my assumption correct?   Will
the TestListener approach help me?

--James

--- In junit@yahoogroups.com, "J. B.   Rainsberger" <jbrains@...> wrote:
>
> james_adams   wrote:
>
> > I have inherited some code which runs a suite of   JUnit test cases (via
> >   junit.textui.TestRunner.doRun(mySuite)) and outputs the results   of the
> > test case either as "." for a success, or ".F" for a   failure, followed
> > by the errors and a summary of the run results.   So if I have three
> > test cases in the suite, and the first and   third test cases succeed,
> > then the output file looks like "..F."   followed by the errors and a
> > summary of how many   successes/failures. There are about 80 test cases
> > in the suite   I'm working with, and it is very time consuming and error
> > prone   to try to figure out which tests succeeded and which ones failed
> >   from a long list of dots and dot-F's. What I would like instead is to
>   > have the report look something like this:
> >
> >   test-01-01: success
> > test-01-02: failure
> > test-02-01:   success
> >
> > <errors>
> >
> >   <summary>
> >
> > I have looked at the JavaDoc for   junit.textui.TestRunner and there is
> > no way to specify how   the final report comes out, more specifically no
> > way to tell it   to print the name of the test case and the result
> > rather than   either "." for success or ".F" for failures.
> >
> > Can   anyone advise me how I can modify this behavior? Am I stuck and
> >   just need to write a parser to convert the "..F." to a meaningful
> >   report as to which tests succeeded or failed (as in the   above
example)?
>
> You're not stuck writing a parser.   Instead, you can write a
TestListener
> that generates the kind of   report you'd like to generate. I've taken
the
> liberty of sending   you (privately) a recipe from _JUnit Recipes_ on the
> topic. I have   found it easiest to use the JUnit-addons test runner and
> plug in   whatever test listeners I want.
>
> Take care.
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.info
> Your   guide to software craftsmanship
> JUnit Recipes: Practical Methods for   Programmer Testing
> 2005 Gordon Pask Award for contribution Agile   Software   Practice
>



    #ygrp-mlmsg { FONT-SIZE: small; FONT-FAMILY:
arial,helvetica,clean,sans-serif}#ygrp-mlmsg TABLE { }#ygrp-mlmsg SELECT { FONT:
99% arial,helvetica,clean,sans-serif}INPUT { FONT: 99%
arial,helvetica,clean,sans-serif}TEXTAREA { FONT: 99%
arial,helvetica,clean,sans-serif}#ygrp-mlmsg PRE { FONT: 100% monospace}CODE {
FONT: 100% monospace}#ygrp-mlmsg * { LINE-HEIGHT: 1.22em}#ygrp-text {
FONT-FAMILY: Georgia}#ygrp-text P { MARGIN: 0px 0px 1em}#ygrp-tpmsgs { CLEAR:
both; FONT-FAMILY: Arial}#ygrp-vitnav { FONT-SIZE: 77%; MARGIN: 0px;
PADDING-TOP: 10px; FONT-FAMILY: Verdana}#ygrp-vitnav A { PADDING-RIGHT: 1px;
PADDING-LEFT: 1px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px}#ygrp-actbar { CLEAR:
both; MARGIN: 25px 0px; COLOR: #666; WHITE-SPACE: nowrap; TEXT-ALIGN:
right}#ygrp-actbar .left { FLOAT: left; WHITE-SPACE: nowrap}..bld { FONT-WEIGHT:
bold}#ygrp-grft { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 77%;
PADDING-BOTTOM: 15px; PADDING-TOP: 15px; FONT-FAMILY:
  Verdana}#ygrp-ft { PADDING-RIGHT: 0px; BORDER-TOP: #666 1px solid;
PADDING-LEFT: 0px; FONT-SIZE: 77%; PADDING-BOTTOM: 5px; PADDING-TOP: 5px;
FONT-FAMILY: verdana}#ygrp-mlmsg #logo { PADDING-BOTTOM: 10px}#ygrp-vital {
PADDING-RIGHT: 0px; PADDING-LEFT: 8px; MARGIN-BOTTOM: 20px; PADDING-BOTTOM: 8px;
PADDING-TOP: 2px; BACKGROUND-COLOR: #e0ecee}#ygrp-vital #vithd { FONT-WEIGHT:
bold; FONT-SIZE: 77%; TEXT-TRANSFORM: uppercase; COLOR: #333; FONT-FAMILY:
Verdana}#ygrp-vital UL { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM:
0px; MARGIN: 2px 0px; PADDING-TOP: 0px}#ygrp-vital UL LI { CLEAR: both;
BORDER-RIGHT: #e0ecee 1px solid; BORDER-TOP: #e0ecee 1px solid; BORDER-LEFT:
#e0ecee 1px solid; BORDER-BOTTOM: #e0ecee 1px solid; LIST-STYLE-TYPE:
none}#ygrp-vital UL LI .ct { PADDING-RIGHT: 0.5em; FONT-WEIGHT: bold; FLOAT:
right; WIDTH: 2em; COLOR: #ff7900; TEXT-ALIGN: right}#ygrp-vital UL LI .cat {
FONT-WEIGHT: bold}#ygrp-vital A { TEXT-DECORATION: none}#ygrp-vital A:hover {
	 TEXT-DECORATION: underline}#ygrp-sponsor #hd { FONT-SIZE: 77%; COLOR:
#999}#ygrp-sponsor #ov { PADDING-RIGHT: 13px; PADDING-LEFT: 13px; MARGIN-BOTTOM:
20px; PADDING-BOTTOM: 6px; PADDING-TOP: 6px; BACKGROUND-COLOR:
#e0ecee}#ygrp-sponsor #ov UL { PADDING-RIGHT: 0px; PADDING-LEFT: 8px;
PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px}#ygrp-sponsor #ov LI {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 77%; PADDING-BOTTOM: 6px;
PADDING-TOP: 6px; LIST-STYLE-TYPE: square}#ygrp-sponsor #ov LI A { FONT-SIZE:
130%; TEXT-DECORATION: none}#ygrp-sponsor #nc { PADDING-RIGHT: 8px;
PADDING-LEFT: 8px; MARGIN-BOTTOM: 20px; PADDING-BOTTOM: 0px; PADDING-TOP: 0px;
BACKGROUND-COLOR: #eee}#ygrp-sponsor .ad { PADDING-RIGHT: 0px; PADDING-LEFT:
0px; PADDING-BOTTOM: 8px; PADDING-TOP: 8px}#ygrp-sponsor .ad #hd1 { FONT-WEIGHT:
bold; FONT-SIZE: 100%; COLOR: #628c2a; LINE-HEIGHT: 122%; FONT-FAMILY:
Arial}#ygrp-sponsor .ad A { TEXT-DECORATION: none}#ygrp-sponsor .ad A:hover {
TEXT-DECORATION:
  underline}#ygrp-sponsor .ad P { MARGIN: 0px}o { FONT-SIZE: 0px}..MsoNormal {
MARGIN: 0px}#ygrp-text TT { FONT-SIZE: 120%}BLOCKQUOTE { MARGIN: 0px 0px 0px
4px}..replbq { }

---------------------------------
  Try the all-new Yahoo! Mail . "The New Version is radically easier to use" –
The Wall Street Journal

[Non-text portions of this message have been removed]

On 8/2/06, Cédric Beust ♔ <cbeust@...> wrote:
> On 8/2/06, Kevin Lawrence <kev.lawrence@...> wrote:
> >
> >
> > It's tempting to start a new thread asking if there is anyone NOT
> > using junit during development ;-)
>
>
> Not everybody uses JUnit, you know...
>

I know.

I was assuming that the OP was using 'junit' to mean 'an automated
unit test framework'. I could have made that clearer.

Kevin

On Aug 2, 2006, at 1:16 PM, junit@yahoogroups.com wrote:

4. Best JUnit tester is the senior software developer. But senior
guys hate
to write test cases.

Senior guys who hate writing tests are not senior guys.  Writing
tests is a matter of professional ethics.  The only way to truly know
that the code you have written works, and works in the whole system,
is to have, and run, a comprehensive set of tests.  Code coverage for
these tests should be very close to 100% (i.e. high 90s).  If you
don't have this, then you don't KNOW that your code actually works.
And shipping code that you aren't as certain as possible about is
unprofessional.

I wear a green band on my wrist that says "Test First".  (http://
butunclebob.com/ArticleS.UncleBob.GreenWristBand)
It is a symbol of my commitment to produce the best code I can, and
to be sure that it works to the best of my ability.  It reminds me to
write tests, to write them first, and to write them diligently.

The argument about "TIME" is laughable.  It is like saying that we
don't have time to test, but we DO have time to debug.  That's an
unprofessional attitude.  Time spent writing tests is time that will
prevent us from having to debug.  Time spent writing tests is time
spent designing, is time spent thinking, and is time spent making
sure that our code can be checked again, and again, and again.

Anyone who says that they don't have time to write tests should not
be writing code.
                  |

----
Robert C. Martin (Uncle Bob)  | email: unclebob@...
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |






[Non-text portions of this message have been removed]

Hi Rob,

On 8/2/06, Robert Martin <UncleBob@...> wrote:
>
>
> The argument about "TIME" is laughable.  It is like saying that we
> don't have time to test, but we DO have time to debug.


You seem to imply that there are only two kinds of code:

    - Code that is tested and works
    - Code that is not tested and doesn't work

There is actually something in the middle:  it's called "Code that is not
tested but that works".

It's a fairly common occurrence, in my experience, and the reason behind my
comments earlier:  if other circumstances warrant it, it's okay to write the
code, ship it and write the tests later.

Just use your judgment, that's why your employer is paying you.

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

james_adams wrote:

> Joe thanks for the recipe. I avoided taking that route before since
> <junit> and <junitreport> were such an improvement over what I had
> originally. However (I think) I have run up against a limitation of
> the <junit> task which makes me revisit this solution. The <junit>
> task isn't working for me because it won't allow you to control how
> much exception stack trace information is kept for each failure. I
> only want to see the first line or two (the only really useful info in
> the exception stack), but I want to limit the amount of exceptions
> that are reported because I appear to be running out of memory when I
> run a full test suite of over 80 tests. This never happened before I
> started using Ant/<junit>/<junitreport>, and my assumption is that the
> exception stacks for each failure are being kept in memory by the
> <junit> task, which is expecting to write all of the info to XML once
> the suite completes. Unfortunately after so many failures the
> exception stack info being held in memory is so much that the program
> crashes with an out-of-memory error. Is my assumption correct? Will
> the TestListener approach help me?

Using your own TestListener won't solve the OutOfMemory problem,
although it might delay the problem a bit further, unless, of course,
you use the TestListener to write all that information out to disk
first, then after running the tests, read that back from disk to process it.
--
J. B. (Joe) Rainsberger :: http://www.jbrains.info
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

> Hi Rob,
>
> On 8/2/06, Robert Martin <UncleBob@...> wrote:
> >
> >
> > The argument about "TIME" is laughable. It is like saying that we
> > don't have time to test, but we DO have time to debug.
>
> You seem to imply that there are only two kinds of code:
>
> - Code that is tested and works
> - Code that is not tested and doesn't work
>
> There is actually something in the middle: it's called "Code that is not
> tested but that works".
>
> It's a fairly common occurrence, in my experience, and the reason behind
my
> comments earlier: if other circumstances warrant it, it's okay to write
the
> code, ship it and write the tests later.
>
> Just use your judgment, that's why your employer is paying you.
>
> --
> Cédric
> http://testng.org

Burn the heretic! :-)

Michael Rutherfurd


**************   IMPORTANT MESSAGE  **************
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential.
If you are not the intended recipient please advise the sender by return email,
do not use or disclose the contents, and delete the message and any attachments
from your system. Unless specifically indicated, this email does not constitute
formal advice or commitment by the sender or the Commonwealth Bank of Australia
(ABN 48 123 123 124) or its subsidiaries.
We can be contacted through our web site: commbank.com.au.
If you no longer wish to receive commercial electronic messages from us, please
reply to this e-mail by typing Unsubscribe in the subject line.
***************************************************************

On 8/2/06, Rutherford, Michael <michael.rutherford@...> wrote:
>
>
> > You seem to imply that there are only two kinds of code:
> >
> > - Code that is tested and works
> > - Code that is not tested and doesn't work
> >
> > There is actually something in the middle: it's called "Code that is not
> > tested but that works".
> >
> > It's a fairly common occurrence, in my experience, and the reason behind
> my
> > comments earlier: if other circumstances warrant it, it's okay to write
> the
> > code, ship it and write the tests later.
> >
> > Just use your judgment, that's why your employer is paying you.
> >
> > --
> > Cédric
> > http://testng.org
>
> Burn the heretic! :-)


Hehe...  If I'm a heretic because I recommend using your common sense
instead of one-liners such as "always test first", then yes, guilty as
charged :-)

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

Cédric Beust ♔ wrote:

>
>You seem to imply that there are only two kinds of code:
>
>   - Code that is tested and works
>   - Code that is not tested and doesn't work
>
>There is actually something in the middle:  it's called "Code that is not
>tested but that works".
>
>
How do you know? ;-)

Michael Feathers
www.objectmentor.com

On 8/2/06, Michael Feathers <mfeathers@...> wrote:
>
> Cédric Beust ♔ wrote:
>
> >
> >You seem to imply that there are only two kinds of code:
> >
> >   - Code that is tested and works
> >   - Code that is not tested and doesn't work
> >
> >There is actually something in the middle:  it's called "Code that is not
> >tested but that works".
> >
> >
> How do you know? ;-)


Because a lot of software companies are still in business and I know for a
fact they don't do a lot of testing :-)

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

Jean,

Thanks for sending your message.  Every tool manages to frustrate some
people, even JUnit.  :-)  But it's very valuable to get feedback from
frustrated users who are still trying to make things work.

You have a lot of specific questions, and if you choose to highlight one
at a time, I think you'll get some really good answers from this
community.

But I was struck by your first real statement: "I have to say it's fun
to do the implement coding. But it's suffering to write JUnit cases."
It made me think a lot.  I got into JUnit because I really _liked_
writing test cases.  But I really respect some people that have been
really frustrated, like you are.  Is there more going on here than
personal preference?  I think there might be.

I thought a lot about it, and, sadly, wrote even more.  Rather than
burden the list with it, I've moved my thoughts over to my tech blog:

http://shareandenjoy.saff.net

Good luck,

     David Saff

Jean wrote:
> I've written JUnit cases for over 1 month.
>
> I have to say it's fun to do the implement coding. But it's suffering to
> write JUnit cases. Because:
> 1. I need to know the correct result from the other way around and sometimes
> it's hard to find another way.
> 2. Database and JSP pages are difficult to JUnit test.
> 3. Mock objects brings more than double efforts during the whole develop
> process.
> 4. Exception situation is not so easy to make as JUnit claims.
>
> 3 friends in 3 different companies (small size and middle size company)
> complain JUnit as:
> 1. They planned JUnit testing firstly and they cannot keep it going. TIME
> reason?
> 2. It consumes a lot of time but hard to find big problems. JUnit does find
> small problems as we expected.
> 3. JUnit testing is not effcient enough.
> 4. Best JUnit tester is the senior software developer. But senior guys hate
> to write test cases.
> 5. For small company, it's really hard to choose between JUnit+develop and
> develop+functional testing.
>
> Is there anyone who is successful in deploying JUnit during develop as:
> JUnit + code + JUnit + code + System Testing?
>

Cédric Beust ♔ wrote:
> On 8/2/06, Michael Feathers <mfeathers@...> wrote:
>
>> Cédric Beust ♔ wrote:
>>
>>> You seem to imply that there are only two kinds of code:
>>>
>>>   - Code that is tested and works
>>>   - Code that is not tested and doesn't work
>>>
>>> There is actually something in the middle:  it's called "Code that is not
>>> tested but that works".
>>>
>> How do you know? ;-)
>>
> Because a lot of software companies are still in business and I know for a
> fact they don't do a lot of testing :-)
>


This thread has, in my opinion, already veered away from the original
poster's question, which seemed to be more about whether it was valuable
to use JUnit at all, rather than whether we should use any kind of
testing, JUnit or not, or whether we should test all the time, or just
most of the time.  But since we're already in this territory...

I recently had the great pleasure of reading the entirety of DeMarco and
Lister's _Peopleware_ in a single day (half of it on the beach, no
less).  One idea from the book really struck me.  I don't remember the
exact wording, so I'll inaccurately paraphrase it: "companies that
merely want to keep their best customers can make do with less quality
than those that want to keep their best employees."  Customers only want
good-enough products.  Your best employees are only really satisfied
with rock-solid products that they're proud to show their kids.  Of
course, companies that begin losing their best employees won't be able
to keep their best customers forever...

This is a provocative statement, and I'm not sure if I really believe it
yet.  If it is true, then how does this impact how we think about
software testing?

     David Saff

Hi David, and thanks for stepping in.

On 8/2/06, David Saff <saff@...> wrote:

> This thread has, in my opinion, already veered away from the original
> poster's question, which seemed to be more about whether it was valuable
> to use JUnit at all, rather than whether we should use any kind of
> testing, JUnit or not, or whether we should test all the time, or just
> most of the time.  But since we're already in this territory


I'm not sure we moved away from the original topic.

The original poster was basically asking "I don't like writing tests, I
don't always to test driven design, is it bad?".

The traditional answer to this question on this mailing-list is "Yes" and "I
do 100% TDD and it works great, what's wrong with you?".

My experience differs.

I don't always do TDD and I claim that very few people do.

It doesn't mean that their software is worthless or that they are bad
developers.  As you very insightfully point out, the taste for testing is
very personal.  Some people love it.  Some people hate it.  Most people
don't feel very strongly either way, but they do have customers, deadlines
and inflexible bosses to respond to.  And I think it's our duty to listen to
them and help them out.

I'll just repeat what I said in my previous email:  most of the software out
there is 1) not tested and 2) works great.

I'd like everybody to reflect on that for a while before I send my next
message...

--
Cédric
http://testng.org


[Non-text portions of this message have been removed]

--- In junit@yahoogroups.com, jason r tibbetts <tibbettj@...> wrote:

> If the app class has a non-private constructor, then your tests don't
> need to instantiate it as a singleton, right? And you also modifed the
> app class so that you can suppress the loading of the UI modules. What,
> then, is impossible about having some tests instantiate the app without
> the UI bits, and other tests that do?

Nothing at all - that's exactly how it works right now. It only bugs
me that I need to be extremely cautious about eg. closing documents
opened by the tested application - otherwise they don't get "killed"
once the test is over, as everything is kept track of by the static,
everlasting instance, and might lead to unexpected interference.
That's why I wondered if what I do still comprises to the separateness
principle - but as I see nobody raises a protest.

Thanks,

Anna