[Jeff Langr...]
>What if instead of being a count, it was a simple visual symbol that
>showed,
>for a given test class, that there is now a new assert that is being run
>for
>the first time?
>(could be a royal pain to figure out... consider if asserts are changed
>or deleted)

Do you care whether the assert is run for the first time, or simply that it
still fails? I suppose one possibility is that the assert is run, passes and
you're surprised. That should shock you immediately and not allow you to
forget. :)

>Or am I just slower than the majority of developers?

No. You are, however, humbler.

JBR.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Another tip.  Sometimes you might want to purposefully throw an
exception.  (Compared to the recent try{}catch and "throws Exception"
discussions).

Suppose you are implementing a static suite() method.  The method
constructs a test suite using repeated calls to Suite.addTest().
Maybe it fills the Suite by reading test cases out of a text file or
walking through an XML DOM.  The suite() code could throw an
exception during this addTest() loop.  What should you do?  Rather
than bailing out, skipping the test, or printing a stack trace to the
console, add a custom exception test to the suite.  This will let the
other tests run fine and cause the bad test to be logged and counted
as a failure.

Here's an example:

static class RecordFailedException extends TestCase {
    Exception e;

    RecordFailedException(String name) {
       super(name);
    }

    RecordFailedException(String fakeName, Exception e) {
       super(fakeName);
       this.e = e;
    }

    public void runTest() throws Exception {
       throw e;
    }
}

public static Test suite() {
   TestSuite suite = new TestSuite();

   ...
   for (int i = 0; i < arrayOfTests.length; ++i) {
      try {
         Object test = ... something that might throw MyException ...;
         suite.addTest(test);
      } catch (MyException e) {
        suite.addTest(new RecordFailedException(arrayOfTests[i].name,
e));
      }
    }
    return suite;
}

> -----Original Message-----
> From: J. B. Rainsberger [mailto:jbrains762@...]
> Sent: Friday, July 27, 2001 12:59 PM
> To: junit@yahoogroups.com
> Subject: [junit] Still counting asserts...
>
> Do you care whether the assert is run for the first time, or
> simply that it
> still fails? I suppose one possibility is that the assert is
> run, passes and
> you're surprised. That should shock you immediately and not
> allow you to
> forget. :)

Maybe both, but foremost the first -- I'd like to know that the assert was
picked up.

While I know the goal is to add assertions that should fail, I do sometimes
end up with assertions that pass immediately, and I can't always figure out
a way to have avoided that.

Several times when I tried to do test on a package and test number turned out
to be a little bit off, I went in and checked my metod that constructing the
test suite.  It turned out that I have made a mistake and there were some tests
not being included while they should.

In this case, test count works for me.

"Kelso, JP Phil (5502)" wrote:

> Why then does JUnit count tests?
>
> > ----------
> > From:         kentbeck@...[SMTP:kentbeck@...]
> > Reply To:     junit@yahoogroups.com
> > Sent:         Friday, July 27, 2001 1:12 PM
> > To:   junit@yahoogroups.com
> > Subject:      [junit] Re: re - assert counting
> >
> > Are folks worried about accidentally leaving asserts out of methods,
> > or about evil programmers boosting their test count by writing bogus
> > tests?
> >
> > Kent
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > junit-unsubscribe@yahoogroups.com
> >
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Well, you could save yourself the trouble and use the ExpectationList from the
mock objects library ;-)

ExpectationList myListOfThings = new ExpectationList("List Of Things");

public void setExpectedThings(Thing[] things) {
   myListOfThings.addExpectedMany(things);
}

public void myRealMethod(Thing eachThing) {
   myListOfThings.addActual(eachThing);
}

public void verify() {
   myListOfThings.verify();
}


----- Original Message -----
From: "J. B. Rainsberger" <jbrains762@...>
To: <junit@yahoogroups.com>
Sent: Friday, July 27, 2001 5:47 PM
Subject: [junit] assertEquals(array1, array2)


> >In this example you may want to write a custom assert().  You don't
> >give the types of the arrays nor their expected lengths (do they hold
> >a few simple elements, dozens of complicated ones, millions, ...).
> >Perhaps you'd be better off constructing a vector of differences and
> >asserting the vector as empty.  Adding the differences to a string
> >and asserting it as equal to "".  Or counting the differences and
> >assertEquals(0, count).
>
> [...]
> This builds up a list of differences. The list knows how to present itself
> as a string (List does that). Each difference presents itself as a string
> (ArrayDifference does that). If you need prettier output, create a class
> that wraps a List of ArrayDifferences and makes the output prettier.
>
> I like the sound of this technique. I think I'll put this up as a best
> practice until someone else tells me something wrong with it.

Hi all,
I'm new to using JUnit and I have a question on how to handle the
following situation.

I have ClassA which accepts a Collection of objects in its
constructor and constructs a tree structure from it. In response to
messages from other classes, ClassA must modify the state of this
tree that it has constructed.

So I have a TestClassA TestCase which has a method testDoSomething()
which calls the "state changing" method on ClassA. Now, how do I
assert whether the states have changed correctly? The TestClassA does
not have access to the internal tree of ClassA.

I have already written separate TestCases for the objects (nodes)
making up the tree and those individual tests seem to be working
fine. Does this mean that I do not need to test this from the
container class? Or is there some other way to do this?

Any help appreciated.
Thanks,
--Das

>Another example:
>// For two arrays: expected, actual

If I wanted this to work, I would code a utility method that does the
comparaison:

public void assertArraysEquals(Objectp[] excepected, Object[] actual) throws
Exception{
     boolean notEquals = false;
     String msg =null;
      if (expected.length != actual.length) {
         notEquals = true; msg = "Lenght not equals";
     }else {
           for (int i = Math.min(expected.length-1, actual.length-1); i >=
0;i--)
           {
             if (!expected[i].euqals( actual[i])) {
                     notEquals=true;
                     msg="Values for index " + i + " aren't equals";
             }
           }
     }
     if (notEquals) {  fail(msg + "actual array values are...." +
arrayToString(actual) )  };
}

This gives you, in that particular case, what you said you wanted, i.e. the
information to be able to debug the problem without going into the debugger.
It's a little bit more work, but you sort of get what you want.

Mathieu

----- Original Message -----
From: Robert Sartin
To: junit@yahoogroups.com
Sent: Tuesday, July 24, 2001 7:56 PM
Subject: RE: [junit] Reporting more then 1 failed assertion per test



--- Vladimir Bossicard <vladimir@...> wrote:
> To "correct" that, you have to change the framework (record the
> errors and throw an exception at the end of the test method).  But I
> really don't think that this will solve problems:

Yes, changing that aspect of the framework would be a very significant,
and challenging, change. It'd be interesting to see how well it could
be done without having to change other interfaces or any existing
tests. Perhaps by having the assert* methods find the test context (a
slightly new/changed concept) in which they are running and logging the
failure there.

>    assertTrue(obj != null);
>    assertTrue(obj.status() == 3);

This would throw a NullPointerException (we really can't change the
behavior of the JVM) in the second assertTrue. The framework might deal
with an Exception from a test that had already failed an assertion as
meaningless and not to be recorded, or might be clever about what
should be recorded.

Another example:

   // For two arrays: expected, actual
   assertEquals(expected.length, actual.length);
   for (int i = Math.min(expected.length-1, actual.length-1); i >= 0;
i--)
   {
     assertEquals(expected[i], actual[i]);
   }

This would log a complete list of incorrect elements in addition to the
size being wrong. So, this example just goes to show that multiple
reporting might be helpful in some circumstances. Obviously not all,
and quite possibly not useful enough for the sizeable and challenging
framework change required to support it.

Regards,

Rob


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

>re - assert countingFrom: Keith Ray
> >As I said before, I would just want a warning when a test method is empty
>or has no asserts...
> > but I don't want to go to the trouble of getting some code-coverage tool
>working.
>
>Interesting. But in my case I would have a lot of "false warnings" because
>I
>have a lot of methods that validate something and throw if it's invalid
>(but
>do nothing if valid, so return is void). The tests look like that :
>
>public void testAValidationTest() throws Exception {
>     validator.validate(VALID_DATA);
>}
>
>So, no asserts, but a perfectly valid test case.

I disagree. Wouldn't method validate(DataObject) have to either return a
boolean or perform the assertion itself? In the first case, you'd have to
write assertTrue(validator.validate()), or otherwise the assertTrue() would
be inside the method validate(). Either way, you're performing at least one
assert.

Of course, I assume that you prefer not to have an unsuccessful validation
register as an error. In the last case, you'd write

try {
     validate();
}
catch (ValidationException oops) {
     fail(oops.toString());
}

Remember, folks: fail() is an assertion! Look at the code.

JBR.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--- "J. B. Rainsberger" <jbrains762@...> wrote:
> try {
>     validate();
> }
> catch (ValidationException oops) {
>     fail(oops.toString());
> }
>
> Remember, folks: fail() is an assertion! Look at the code.

Right, but fail will only be called if the test fails, while assert
will be called to test if the test should fail.

So, code that dyamically counts assertions will count the above as
having no assertions if it passes.

Some people in this discussion seem to be assuming a static analysis of
the code to be an included, or perhaps the only, mechanism in the
assertion counting. I can imagine (OK, no imagination, I have used)
tools that do that, but I can't see the need for it in a lightweight
unit testing framework. I'm still unconvinced that dynamic counts are
that valuable, but at the very low cost of dynamic counts, the value
doesn't have to be too high.

Regards,

Rob




__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

>Are folks worried about accidentally leaving asserts out of methods,
>or about evil programmers boosting their test count by writing bogus
>tests?

From what I can tell, more of the first than the second. I was never
concerned about either; however, it seems like some folks are concerned
about writing a test, being interrupted part way through, then forgetting to
assert something.

Let me share my experience with this. The most common mistake I make is
this:

public void testNullParameters() {
     try {
         A a = new A(null);
     }
     catch (IllegalArgumentException success) {
     }
}

This test passes, even though I know I didn't write the exception throwing
code. So I curse myself, add the fail() statement and move on. The great
thing is that it only takes 15 seconds to verify that I made a mistake. Mind
you, this is a simple case, so you may experience different things. Counting
assertions likely would not have helped me there.

If you're concerned about forgetting to assert, try this:

public void testMethod() {
     fail("NYI");   // "Not yet implemented"
}

The rule is: don't remove the fail statement until you're satisfied that the
test is correct. Do this until you don't forget to assert something as
often. I guess this is a "study" within test-first programming. :)

JBR.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

> > Do you care whether the assert is run for the first time, or
> > simply that it
> > still fails? I suppose one possibility is that the assert is
> > run, passes and
> > you're surprised. That should shock you immediately and not
> > allow you to
> > forget. :)
>
>Maybe both, but foremost the first -- I'd like to know that the assert was
>picked up.
>
>While I know the goal is to add assertions that should fail, I do sometimes
>end up with assertions that pass immediately, and I can't always figure out
>a way to have avoided that.

Hm. Why are you so concerned about it? Sometimes you write assertions that
pass because you refactored earlier to a more general case. That's not
necessarily a bad thing, is it?

If the assertion you just wrote is incorrect, then you have a pretty narrow
section of code to doublecheck. The only way to avoid that is not to make
mistakes. Good luck with that. :)

JBR.
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>Message: 20
>    Date: Fri, 27 Jul 2001 13:11:22 -0700
>    From: Shane Duan <sduan@...>
>Subject: Re: Re: re - assert counting
>
>Several times when I tried to do test on a package and test number turned
>out
>to be a little bit off, I went in and checked my metod that constructing
>the
>test suite.  It turned out that I have made a mistake and there were some
>tests
>not being included while they should.
>
>In this case, test count works for me.
>
>"Kelso, JP Phil (5502)" wrote:
>
> > Why then does JUnit count tests?
> >
> > > ----------
> > > From:         kentbeck@...[SMTP:kentbeck@...]
> > > Reply To:     junit@yahoogroups.com
> > > Sent:         Friday, July 27, 2001 1:12 PM
> > > To:   junit@yahoogroups.com
> > > Subject:      [junit] Re: re - assert counting
> > >
> > > Are folks worried about accidentally leaving asserts out of methods,
> > > or about evil programmers boosting their test count by writing bogus
> > > tests?
> > >
> > > Kent
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > junit-unsubscribe@yahoogroups.com
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
>http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> >
> > To unsubscribe from this group, send an email to:
> > junit-unsubscribe@yahoogroups.com
> >
> >
> > Your use of Yahoo! Groups is subject to
>http://docs.yahoo.com/info/terms/
>
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>Message: 21
>    Date: Fri, 27 Jul 2001 21:21:29 +0100
>    From: "Steve Freeman" <steve@...>
>Subject: Re: assertEquals(array1, array2)
>
>Well, you could save yourself the trouble and use the ExpectationList from
>the mock objects library ;-)
>
>ExpectationList myListOfThings = new ExpectationList("List Of Things");
>
>public void setExpectedThings(Thing[] things) {
>   myListOfThings.addExpectedMany(things);
>}
>
>public void myRealMethod(Thing eachThing) {
>   myListOfThings.addActual(eachThing);
>}
>
>public void verify() {
>   myListOfThings.verify();
>}
>
>
>----- Original Message -----
>From: "J. B. Rainsberger" <jbrains762@...>
>To: <junit@yahoogroups.com>
>Sent: Friday, July 27, 2001 5:47 PM
>Subject: [junit] assertEquals(array1, array2)
>
>
> > >In this example you may want to write a custom assert().  You don't
> > >give the types of the arrays nor their expected lengths (do they hold
> > >a few simple elements, dozens of complicated ones, millions, ...).
> > >Perhaps you'd be better off constructing a vector of differences and
> > >asserting the vector as empty.  Adding the differences to a string
> > >and asserting it as equal to "".  Or counting the differences and
> > >assertEquals(0, count).
> >
> > [...]
> > This builds up a list of differences. The list knows how to present
>itself
> > as a string (List does that). Each difference presents itself as a
>string
> > (ArrayDifference does that). If you need prettier output, create a class
> > that wraps a List of ArrayDifferences and makes the output prettier.
> >
> > I like the sound of this technique. I think I'll put this up as a best
> > practice until someone else tells me something wrong with it.
>
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>Message: 22
>    Date: Sat, 28 Jul 2001 01:04:29 -0000
>    From: reply_das@...
>Subject: Newbie question ..
>
>Hi all,
>I'm new to using JUnit and I have a question on how to handle the
>following situation.
>
>I have ClassA which accepts a Collection of objects in its
>constructor and constructs a tree structure from it. In response to
>messages from other classes, ClassA must modify the state of this
>tree that it has constructed.
>
>So I have a TestClassA TestCase which has a method testDoSomething()
>which calls the "state changing" method on ClassA. Now, how do I
>assert whether the states have changed correctly? The TestClassA does
>not have access to the internal tree of ClassA.
>
>I have already written separate TestCases for the objects (nodes)
>making up the tree and those individual tests seem to be working
>fine. Does this mean that I do not need to test this from the
>container class? Or is there some other way to do this?
>
>Any help appreciated.
>Thanks,
>--Das
>
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>Message: 23
>    Date: Tue, 24 Jul 2001 20:29:54 -0400
>    From: "Mathieu Gervais" <egoine_@...>
>Subject: Re: Reporting more then 1 failed assertion per test
>
> >Another example:
> >// For two arrays: expected, actual
>
>If I wanted this to work, I would code a utility method that does the
>comparaison:
>
>public void assertArraysEquals(Objectp[] excepected, Object[] actual)
>throws
>Exception{
>     boolean notEquals = false;
>     String msg =null;
>      if (expected.length != actual.length) {
>         notEquals = true; msg = "Lenght not equals";
>     }else {
>           for (int i = Math.min(expected.length-1, actual.length-1); i >=
>0;i--)
>           {
>             if (!expected[i].euqals( actual[i])) {
>                     notEquals=true;
>                     msg="Values for index " + i + " aren't equals";
>             }
>           }
>     }
>     if (notEquals) {  fail(msg + "actual array values are...." +
>arrayToString(actual) )  };
>}
>
>This gives you, in that particular case, what you said you wanted, i.e. the
>information to be able to debug the problem without going into the
>debugger.
>It's a little bit more work, but you sort of get what you want.
>
>Mathieu
>
>----- Original Message -----
>From: Robert Sartin
>To: junit@yahoogroups.com
>Sent: Tuesday, July 24, 2001 7:56 PM
>Subject: RE: [junit] Reporting more then 1 failed assertion per test
>
>
>
>--- Vladimir Bossicard <vladimir@...> wrote:
> > To "correct" that, you have to change the framework (record the
> > errors and throw an exception at the end of the test method).  But I
> > really don't think that this will solve problems:
>
>Yes, changing that aspect of the framework would be a very significant,
>and challenging, change. It'd be interesting to see how well it could
>be done without having to change other interfaces or any existing
>tests. Perhaps by having the assert* methods find the test context (a
>slightly new/changed concept) in which they are running and logging the
>failure there.
>
> >    assertTrue(obj != null);
> >    assertTrue(obj.status() == 3);
>
>This would throw a NullPointerException (we really can't change the
>behavior of the JVM) in the second assertTrue. The framework might deal
>with an Exception from a test that had already failed an assertion as
>meaningless and not to be recorded, or might be clever about what
>should be recorded.
>
>Another example:
>
>   // For two arrays: expected, actual
>   assertEquals(expected.length, actual.length);
>   for (int i = Math.min(expected.length-1, actual.length-1); i >= 0;
>i--)
>   {
>     assertEquals(expected[i], actual[i]);
>   }
>
>This would log a complete list of incorrect elements in addition to the
>size being wrong. So, this example just goes to show that multiple
>reporting might be helpful in some circumstances. Obviously not all,
>and quite possibly not useful enough for the sizeable and challenging
>framework change required to support it.
>
>Regards,
>
>Rob
>
>
>__________________________________________________
>Do You Yahoo!?
>Make international calls for as low as $.04/minute with Yahoo! Messenger
>http://phonecard.yahoo.com/
>
>To unsubscribe from this group, send an email to:
>junit-unsubscribe@yahoogroups.com
>
>
>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
>________________________________________________________________________
>________________________________________________________________________
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

--- "J. B. Rainsberger" <jbrains762@...> wrote:
> >Are folks worried about accidentally leaving asserts out of methods,
> >or about evil programmers boosting their test count by writing bogus
> >tests?
>
> From what I can tell, more of the first than the second.

So, what I always do is write test like this:

   public void testSomething() {
     fail("Test not implemented");
   }

Then while I'm writing the test, I leave that fail there until I'm
done. I rarely write tests that are complicated enough that I stop in
the middle (I have this rule I try to follow about not leaving my desk
with uncommitted changes to the source repository which requires me to
have working tests). If I do stop in the middle (say, I got interrupted
by the CEO for a conference call with a paying customer), I toss in a
comment with my plan. If I can't pick up the test from there, it
probably means I've headed down the wrong path and should stop and
correct. I don't delete the fail until I think that the test is
complete and the fail() at the end is the only thing keeping it from
passing.

Regards,

Rob


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

>Are folks worried about accidentally leaving asserts
>out of methods[....]

more like forgetting to [finish] writing the tests.

The tone of Jason was tough, but I also agree with his message.

2 major points in my view :
>It is meant to tell you whether or not the code works the way you think it
should.
>It's a SIMPLE framework for developers and testers

mathieu
----- Original Message -----
From: David Roussel
[...]
I agree with this view point.  If your tests fail then you can go
through it and add logging and comment out the asserts so you can see
what's going on.

Pass or fail.

If only all things in life were as simple.
-----Original Message-----
From: Jason Rogers [mailto:jason.rogers@...]
[...]
AAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!

Why do you care?  A test fails or it passes.  Period.

If you want more, JUnit is probably not the framework to use.  The
framework
is not meant to give warm fuzzy feelings (interpretation of green bar),
pains in the gut (interpretation of red bar), or minor headaches (amber
bar?).  It is meant to tell you whether or not the code works the way
you
think it should.  It's a SIMPLE framework for developers and testers,
not a
bogus-meet-all-levels-of-satisfaction-and-feel-goods reporting tool.

Sorry for the outburst of frustration.
-Jason
-----Original Message-----
From: dror2@... [mailto:dror2@...]
Sent: Wednesday, July 25, 2001 7:04 AM
To: junit@yahoogroups.com
Subject: RE: [junit] Reporting more then 1 failed assertion per test

What I think is brought up here is a request for "warning" or
"soft-assertion" level, which is lower than Failure or Error.
warn() should have the interface of assert(), except that it does not
throw
an exception, merely count it. It might still create a Throwable object
(without throwing it), just to have  a stack-trace handy.
[...]

I always compare arrays like this:

assertEquals( Arrays.asList(array1), Arrays.asList(array2) );

Not very helpful diagnostics if the array length is long but it is simple.

--
Neil Swingler

> -----Original Message-----
> From: J. B. Rainsberger [mailto:jbrains762@...]
> Sent: 27 July 2001 17:47
> To: junit@yahoogroups.com
> Subject: [junit] assertEquals(array1, array2)
>
>
> >In this example you may want to write a custom assert().  You don't
> >give the types of the arrays nor their expected lengths (do they hold
> >a few simple elements, dozens of complicated ones, millions, ...).
> >Perhaps you'd be better off constructing a vector of differences and
> >asserting the vector as empty.  Adding the differences to a string
> >and asserting it as equal to "".  Or counting the differences and
> >assertEquals(0, count).
>
> Wow! This is an awesome idea. Let's see if we can take this
> further. Here is
> code off the top of my head.
>
> public class ArrayDifference {
>     public Object expected;
>     public Object actual;
>     public ArrayDifference(Object anExpected, Object anActual) {
>         expected = anExpected;
>         actual = anActual;
>     }
>     public String toString() {
>         return ("Expected <" + expected + "> but got <" + actual + ">";
>     }
> }
>
> public void assertEqualArrays(Object[] expected, Object[] actual) {
>     assertNotNull("expected is null", expected);
>     assertNotNull("actual is null", actual);
>     assertEquals(expected.length, actual.length);
>     final List differences = new ArrayList();
>     for (int i = 0; i < expected.length; i++) {
>         if (expected[i] == null
>             || !(expected[i].equals(actual[i]))) {
>             differences.add(new ArrayDifference(expected[i], actual[i]));
>         }
>     }
>     assertEquals(new ArrayList(), differences);
> }
>
> This builds up a list of differences. The list knows how to
> present itself
> as a string (List does that). Each difference presents itself as a string
> (ArrayDifference does that). If you need prettier output, create a class
> that wraps a List of ArrayDifferences and makes the output prettier.
>
> I like the sound of this technique. I think I'll put this up as a best
> practice until someone else tells me something wrong with it.
>
> JBR.
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Hi all,

I'm new to this group so this may have been asked lots..

I've just started working with JDK 1.4 beta and cannot compile with JUnit due
to the fact that Sun have just added
'assert' as a key word to the language and of course JUnit has been using this
for a long time!

Has there been any discussion on a solution for this?

Thanks,
Jon

-----Message d'origine-----
De : Jon [mailto:Jon]De la part de Jon Ferguson

Hi all,

I'm new to this group so this may have been asked lots..

I've just started working with JDK 1.4 beta and cannot compile with JUnit due
to the fact that Sun have just added
'assert' as a key word to the language and of course JUnit has been using this
for a long time!

Why is the assert in the catch block required? Couldn't it just fall through?
/Håkan

> -----Original Message-----
> From: Jason Rogers [mailto:jason.rogers@...]
> Sent: Saturday, July 14, 2001 5:50 PM
> To: 'junit@yahoogroups.com'
> Subject: RE: [junit] How do I implement a test case for a thrown
> exception ?
>
>
> If you want to eliminate the boolean, use your first example
> and do the
> assert in the catch block.
>
>     public void test_00_isPartnerAssigned() {
>
>         try {
>             instancePartnerHierarchyWorker.isPartnerAssigned(null);
>             fail("IllegalArgumentException should be thrown.");
>
>         } catch (IllegalArgumentException iae) {
>
>             assert(true);
>
>         } catch (PartnerNotFoundException pnfe){
>
>             fail("PartnerNotFoundException should not be thrown.");
>
>         } catch (PersistenceException pe){
>
>             fail("PersistenceException should not be thrown.");
>         }
>     }

How do I do this?  What should I put instead of ${project.name} ?  Sorry if
this is in the docs, I have scoured them but can't find the answer. (I know
that if you put ${basedir} it give what you want.

<project name="myproject" default="echoprojectname" basedir="." >
      <target name="echoprojectname" >
           <echo message="${project.name}"
      </target>
</project>

Thanks,

Rob

Sorry,
I hadn't read the follow-ups.
Please, no flames.
/håkan

> -----Original Message-----
> From: Håkan Danielsson (ERA) [mailto:hakan.danielsson@...]
> Sent: Monday, July 30, 2001 2:51 PM
> To: 'junit@yahoogroups.com'
> Subject: RE: [junit] How do I implement a test case for a thrown
> exception ?
>
>
> Why is the assert in the catch block required? Couldn't it
> just fall through?
> /Håkan
>

Use the latest JUnit and "assertTrue"

> -----Original Message-----
> From: Jon Ferguson [mailto:ferguson@...]
> Sent: Monday, July 30, 2001 7:03 AM
> To: junit@yahoogroups.com
> Subject: Re: [junit] assertEquals(array1, array2)
>
>
> Hi all,
>
> I'm new to this group so this may have been asked lots..
>
> I've just started working with JDK 1.4 beta and cannot
> compile with JUnit due
> to the fact that Sun have just added
> 'assert' as a key word to the language and of course JUnit
> has been using this
> for a long time!
>
> Has there been any discussion on a solution for this?
>
> Thanks,
> Jon
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Small business owners...
> Tell us what you think!
> http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/NhFolB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

Hey Alain,

Right you are!..... just missed it.. and of course the compiler never
had the chance to tell me it was deprecated.

So as long as you're using junit compiled with something other than JDK
1.4
and do not try to use assert, you will not have probs... if you do use
assert you'll get a compiler error before
you get a deprecation warning.

Thanks for the info.. it's exactly what I was looking for.

Jon


Alain RAVET wrote:

>  Jon,In the latest release - 3.7 -, assert has become deprecated, and
> is replaced by assertTrue (..), with the same parametersAlain

This only works for arrays that must be ordered.  What about unordered
arrays?  So, I would extend your example:

public class ArrayDifference {
     public Object expected;
     public Object actual;
     public ArrayDifference(Object anExpected, Object anActual) {
         expected = anExpected;
         actual = anActual;
     }
     public String toString() {
         StringBuffer message = new StringBuffer("Expected <");
         message.append(expected);
         message.append("> but ");

         if(actual != null){
             message.append("got <");
             message.append(actual);
             message.append(">");
         } else {
             message.append("found no match");
         }
         return message.toString();
     }
}

public void assertCommon(Object[] expected, Object[] actual) {
     assertNotNull("expected is null", expected);
     assertNotNull("actual is null", actual);
     assertEquals(expected.length, actual.length);
}

public void assertEqualOrderedArrays(Object[] expected, Object[] actual) {
     assertCommon(expected, actual);
     final List differences = new ArrayList();

     for (int i = 0; i < expected.length; i++) {
         if (expected[i] == null
             || !(expected[i].equals(actual[i]))) {
             differences.add( new ArrayDifference(expected[i], actual[i]) );
         }
     }
     assertEquals(new ArrayList(), differences);
}

public void assertEqualUnorderedArrays(Object[] expected, Object[] actual) {
     assertCommon(expected, actual);
     final List differences = new ArrayList();
     boolean matchFound = false;

     for (int i = 0; i < expected.length; i++) {
         if (expected[i] == null)
             differences.add( new ArrayDifference(expected[i], actual[i]) );
         } else {
             for (int j = 0; j < actual.length; j++){
                 if ( actual[j].equals(expected[i]) ){
                     matchFound = true;
                 }
             }
             if ( !matchFound ){
                 differences.add( new ArrayDifference(expected[i], null) );
             }
         }
     }
     assertEquals(new ArrayList(), differences);
}

-Jason

Jason Rogers <jason.rogers@...> said:

> This only works for arrays that must be ordered.  What about unordered
> arrays?  So, I would extend your example:

or use an ExpectationSet from the mockobjects library on sourceforge (sorry to
be boring...)

ExpectationSet allMyThings = new ExpectationSet("All my things");

...

allMyThings.addExpectedMany(lotsOfThings);

...

public void anActionOnTheSet(Thing aThing) {
   allMyThings.addActual(aThing);
}

...

allMyThings.verify();

Because if the catch that contains the assert does not occur, and no other
exceptions are thrown, you want to fail the test.  The code did not perform
the way it was supposed to... that's a failure indicating broken code.

-Jason

     > -----Original Message-----
     > From: Håkan Danielsson (ERA)
     > [mailto:hakan.danielsson@...]
     > Sent: Monday, July 30, 2001 8:51 AM
     > To: 'junit@yahoogroups.com'
     > Subject: RE: [junit] How do I implement a test case for a thrown
     > exception ?
     >
     >
     > Why is the assert in the catch block required? Couldn't
     > it just fall through?
     > /Håkan
     >
     > > -----Original Message-----
     > > From: Jason Rogers [mailto:jason.rogers@...]
     > > Sent: Saturday, July 14, 2001 5:50 PM
     > > To: 'junit@yahoogroups.com'
     > > Subject: RE: [junit] How do I implement a test case for a thrown
     > > exception ?
     > >
     > >
     > > If you want to eliminate the boolean, use your first example
     > > and do the
     > > assert in the catch block.
     > >
     > >     public void test_00_isPartnerAssigned() {
     > >
     > >         try {
     > >
     > instancePartnerHierarchyWorker.isPartnerAssigned(null);
     > >             fail("IllegalArgumentException should be thrown.");
     > >
     > >         } catch (IllegalArgumentException iae) {
     > >
     > >             assert(true);
     > >
     > >         } catch (PartnerNotFoundException pnfe){
     > >
     > >             fail("PartnerNotFoundException should not
     > be thrown.");
     > >
     > >         } catch (PersistenceException pe){
     > >
     > >             fail("PersistenceException should not be thrown.");
     > >         }
     > >     }
     >
     > ------------------------ Yahoo! Groups Sponsor
     > ---------------------~-->
     > Small business owners...
     > Tell us what you think!
     > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/NhFolB/TM
     > ----------------------------------------------------------
     > -----------~->
     >
     > To unsubscribe from this group, send an email to:
     > junit-unsubscribe@yahoogroups.com
     >
     >
     > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Yup.  I responded before I saw all of the follow-ups :)

     > -----Original Message-----
     > From: Steve Freeman [mailto:steve@...]
     > Sent: Monday, July 30, 2001 10:50 AM
     > To: junit@yahoogroups.com
     > Subject: RE: [junit] assertEquals(array1, array2)
     >
     >
     >
     > Jason Rogers <jason.rogers@...> said:
     >
     > > This only works for arrays that must be ordered.  What
     > about unordered
     > > arrays?  So, I would extend your example:
     >
     > or use an ExpectationSet from the mockobjects library on
     > sourceforge (sorry to be boring...)
     >
     > ExpectationSet allMyThings = new ExpectationSet("All my things");
     >
     > ...
     >
     > allMyThings.addExpectedMany(lotsOfThings);
     >
     > ...
     >
     > public void anActionOnTheSet(Thing aThing) {
     >   allMyThings.addActual(aThing);
     > }
     >
     > ...
     >
     > allMyThings.verify();
     >
     >
     >
     > ------------------------ Yahoo! Groups Sponsor
     > ---------------------~-->
     > Small business owners...
     > Tell us what you think!
     > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/NhFolB/TM
     > ----------------------------------------------------------
     > -----------~->
     >
     > To unsubscribe from this group, send an email to:
     > junit-unsubscribe@yahoogroups.com
     >
     >
     > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Jason, I think Håkan means 'why is the assert(true) there?'.  I doesn't
need to be it just makes the correct execution flow more explicit.

-----Original Message-----
From: Jason Rogers [mailto:jason.rogers@...]
Sent: 30 July 2001 15:56
To: 'junit@yahoogroups.com'
Subject: RE: [junit] How do I implement a test case for a thrown
exception ?


Because if the catch that contains the assert does not occur, and no
other
exceptions are thrown, you want to fail the test.  The code did not
perform
the way it was supposed to... that's a failure indicating broken code.

-Jason

     > -----Original Message-----
     > From: Håkan Danielsson (ERA)
     > [mailto:hakan.danielsson@...]
     > Sent: Monday, July 30, 2001 8:51 AM
     > To: 'junit@yahoogroups.com'
     > Subject: RE: [junit] How do I implement a test case for a thrown
     > exception ?
     >
     >
     > Why is the assert in the catch block required? Couldn't
     > it just fall through?
     > /Håkan
     >
     > > -----Original Message-----
     > > From: Jason Rogers [mailto:jason.rogers@...]
     > > Sent: Saturday, July 14, 2001 5:50 PM
     > > To: 'junit@yahoogroups.com'
     > > Subject: RE: [junit] How do I implement a test case for a thrown
     > > exception ?
     > >
     > >
     > > If you want to eliminate the boolean, use your first example
     > > and do the
     > > assert in the catch block.
     > >
     > >     public void test_00_isPartnerAssigned() {
     > >
     > >         try {
     > >
     > instancePartnerHierarchyWorker.isPartnerAssigned(null);
     > >             fail("IllegalArgumentException should be thrown.");
     > >
     > >         } catch (IllegalArgumentException iae) {
     > >
     > >             assert(true);
     > >
     > >         } catch (PartnerNotFoundException pnfe){
     > >
     > >             fail("PartnerNotFoundException should not
     > be thrown.");
     > >
     > >         } catch (PersistenceException pe){
     > >
     > >             fail("PersistenceException should not be thrown.");
     > >         }
     > >     }
     >
     > ------------------------ Yahoo! Groups Sponsor
     > ---------------------~-->
     > Small business owners...
     > Tell us what you think!
     > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/NhFolB/TM
     > ----------------------------------------------------------
     > -----------~->
     >
     > To unsubscribe from this group, send an email to:
     > junit-unsubscribe@yahoogroups.com
     >
     >
     > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/






To unsubscribe from this group, send an email to:
junit-unsubscribe@yahoogroups.com


Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

If you want Set like behaviour i.e. not containing duplicate entries this
can be done more simply
(but with less diagnostics) like this:

	 assertEquals( new HashSet( Arrays.asList( expectedArray ) ), new
ashSet( Arrays.asList( actualArray ) ) );

assuming the object in the array has a working hashCode.

--
Neil Swingler


> -----Original Message-----
> From: Jason Rogers [mailto:jason.rogers@...]
> Sent: 30 July 2001 15:43
> To: 'junit@yahoogroups.com'
> Subject: RE: [junit] assertEquals(array1, array2)
>
>
> This only works for arrays that must be ordered.  What about unordered
> arrays?  So, I would extend your example:
>
> public class ArrayDifference {
>     public Object expected;
>     public Object actual;
>     public ArrayDifference(Object anExpected, Object anActual) {
>         expected = anExpected;
>         actual = anActual;
>     }
>     public String toString() {
>         StringBuffer message = new StringBuffer("Expected <");
>         message.append(expected);
>         message.append("> but ");
>
>         if(actual != null){
>             message.append("got <");
>             message.append(actual);
>             message.append(">");
>         } else {
>             message.append("found no match");
>         }
>         return message.toString();
>     }
> }
>
> public void assertCommon(Object[] expected, Object[] actual) {
>     assertNotNull("expected is null", expected);
>     assertNotNull("actual is null", actual);
>     assertEquals(expected.length, actual.length);
> }
>
> public void assertEqualOrderedArrays(Object[] expected, Object[] actual) {
>     assertCommon(expected, actual);
>     final List differences = new ArrayList();
>
>     for (int i = 0; i < expected.length; i++) {
>         if (expected[i] == null
>             || !(expected[i].equals(actual[i]))) {
>             differences.add( new ArrayDifference(expected[i],
> actual[i]) );
>         }
>     }
>     assertEquals(new ArrayList(), differences);
> }
>
> public void assertEqualUnorderedArrays(Object[] expected,
> Object[] actual) {
>     assertCommon(expected, actual);
>     final List differences = new ArrayList();
>     boolean matchFound = false;
>
>     for (int i = 0; i < expected.length; i++) {
>         if (expected[i] == null)
>             differences.add( new ArrayDifference(expected[i],
> actual[i]) );
>         } else {
>             for (int j = 0; j < actual.length; j++){
>                 if ( actual[j].equals(expected[i]) ){
>                     matchFound = true;
>                 }
>             }
>             if ( !matchFound ){
>                 differences.add( new ArrayDifference(expected[i], null) );
>             }
>         }
>     }
>     assertEquals(new ArrayList(), differences);
> }
>
> -Jason
>
>
>
> To unsubscribe from this group, send an email to:
> junit-unsubscribe@yahoogroups.com
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

From: J. B. Rainsberger :
>If you're concerned about forgetting to assert, try this:
>public void testMethod() {
>    fail("NYI");   // "Not yet implemented"
>}

I also used that from time to time. Like when I get interrupted.

mathieu

Oh... :)

     > -----Original Message-----
     > From: David Roussel [mailto:dir@...]
     > Sent: Monday, July 30, 2001 11:01 AM
     > To: junit@yahoogroups.com
     > Subject: RE: [junit] How do I implement a test case for a thrown
     > exception ?
     >
     >
     > Jason, I think Håkan means 'why is the assert(true)
     > there?'.  I doesn't
     > need to be it just makes the correct execution flow more explicit.
     >
     > -----Original Message-----
     > From: Jason Rogers [mailto:jason.rogers@...]
     > Sent: 30 July 2001 15:56
     > To: 'junit@yahoogroups.com'
     > Subject: RE: [junit] How do I implement a test case for a thrown
     > exception ?
     >
     >
     > Because if the catch that contains the assert does not
     > occur, and no
     > other
     > exceptions are thrown, you want to fail the test.  The
     > code did not
     > perform
     > the way it was supposed to... that's a failure indicating
     > broken code.
     >
     > -Jason
     >
     >     > -----Original Message-----
     >     > From: Håkan Danielsson (ERA)
     >     > [mailto:hakan.danielsson@...]
     >     > Sent: Monday, July 30, 2001 8:51 AM
     >     > To: 'junit@yahoogroups.com'
     >     > Subject: RE: [junit] How do I implement a test case
     > for a thrown
     >     > exception ?
     >     >
     >     >
     >     > Why is the assert in the catch block required? Couldn't
     >     > it just fall through?
     >     > /Håkan
     >     >
     >     > > -----Original Message-----
     >     > > From: Jason Rogers [mailto:jason.rogers@...]
     >     > > Sent: Saturday, July 14, 2001 5:50 PM
     >     > > To: 'junit@yahoogroups.com'
     >     > > Subject: RE: [junit] How do I implement a test
     > case for a thrown
     >     > > exception ?
     >     > >
     >     > >
     >     > > If you want to eliminate the boolean, use your
     > first example
     >     > > and do the
     >     > > assert in the catch block.
     >     > >
     >     > >     public void test_00_isPartnerAssigned() {
     >     > >
     >     > >         try {
     >     > >
     >     > instancePartnerHierarchyWorker.isPartnerAssigned(null);
     >     > >             fail("IllegalArgumentException should
     > be thrown.");
     >     > >
     >     > >         } catch (IllegalArgumentException iae) {
     >     > >
     >     > >             assert(true);
     >     > >
     >     > >         } catch (PartnerNotFoundException pnfe){
     >     > >
     >     > >             fail("PartnerNotFoundException should not
     >     > be thrown.");
     >     > >
     >     > >         } catch (PersistenceException pe){
     >     > >
     >     > >             fail("PersistenceException should not
     > be thrown.");
     >     > >         }
     >     > >     }
     >     >
     >     > ------------------------ Yahoo! Groups Sponsor
     >     > ---------------------~-->
     >     > Small business owners...
     >     > Tell us what you think!
     >     > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/NhFolB/TM
     >     > ----------------------------------------------------------
     >     > -----------~->
     >     >
     >     > To unsubscribe from this group, send an email to:
     >     > junit-unsubscribe@yahoogroups.com
     >     >
     >     >
     >     > Your use of Yahoo! Groups is subject to
     > http://docs.yahoo.com/info/terms/
     >
     >
     >
     >
     >
     >
     > To unsubscribe from this group, send an email to:
     > junit-unsubscribe@yahoogroups.com
     >
     >
     > Your use of Yahoo! Groups is subject to
     > http://docs.yahoo.com/info/terms/
     >
     >
     >
     > ------------------------ Yahoo! Groups Sponsor
     > ---------------------~-->
     > Secure your servers with 128-bit SSL encryption! Grab
     > your copy of VeriSign's FREE Guide: "Securing Your Web
     > Site for Business." Get it Now!
     > http://www.verisign.com/cgi-bin/go.cgi?a=n094442340008000
     > http://us.click.yahoo.com/n7RbFC/zhwCAA/yigFAA/NhFolB/TM
     > ----------------------------------------------------------
     > -----------~->
     >
     > To unsubscribe from this group, send an email to:
     > junit-unsubscribe@yahoogroups.com
     >
     >
     > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/