if the testFirst and testSecond reuse some of the same code, then put
that shared code into its method(s). Then you don't duplicate quite so
much.

In general though, if you have a failed test, you should fix that test
without worrying what other part of the same test fails.

Hope this helps.
Daniel.

Junit ends the test on the first failure, period.  This can be annoying, say
when you want to run a lengthy process and then check a number of results
and see all the ones that are incorrect..  There's no out-of-the-box way to
accomplish this.   One solution is to write a class that implements the same
assertXXX() methods as TestCase, but, instead of throwing an
AssertionFailedError if they fail, simply notes that a failure occurred,
appends a text description of the failure to a list, and returns.  After
having checked multiple things, call the checkForErrors() method of this
class, which will, if anything has failed, throw an AssertionFailedError
whose message describes all of the failures seen.

This is a common scenario when your fixture (setUp()) takes a long
time to create.  If possible, your setUp() method should set up as
little application state as necessary for the test to exercise.  If
you set up more than that, you risk the possibility that other
unrelated application changes will suddenly cause your tests to fail.

If a minimal fixture still takes a long time to set up, there are
advanced techniques like mocking and stubbing that you can look into,
to isolate your test from environmental conditions that are affecting
the performance of your tests.  Presumably, this is a unit test, not a
system/integration/regression test, correct?  If so, other subsystems
like databases, servers, etc. should not be dependencies of your test,
and should be stubbed out to return expected values.  Test each
component or feature in isolation, so that when a test starts failing,
you know exactly where to start looking.

If you are writing an integration test, then you *do* want the
external dependencies.  In that case, having a fully automated test is
worth the wait.

Fred

Sub: "a simple junit question"

"What is the meaning of life?" is a *simple* quesion
(to ask), but that does not mean the *answer* is
simple.

Simple questions often do not result in simple
*answers*.

So this leads me to enquire why you should
bother mentioning how difficult is was for you
to *ask* the 'simple' question?  Why should
*we* care how difficult it was for you to put
your question into words?