Comments on: Testing antipatterns

By: JavaPins

JavaPins — Sat, 11 Aug 2012 14:17:36 +0000

Testing antipatterns…

Thank you for submitting this cool story – Trackback from JavaPins…

By: jenslukowski

jenslukowski — Thu, 09 Aug 2012 14:16:49 +0000

Yes, we use Joda Time for our projects since it handles many things much better than the built in Date/Calendar libs. The above code is just used Date as an example to not complicate it.
I agree with you that immutable objects are the way to go, it’s one of the things which I find very interesting in languages like Clojure which have builtin immutable or value objects. I’ve read Effective Java but yes, I should re-read it and should adhere more to the rules in there. Immutable objects make using them easier especially in multithreaded environments. Maybe you’ve read it already but I found John Carmack’s approach to using functional programming parts very pragmatic and helpful: http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

By: Eric Jablow

Eric Jablow — Thu, 09 Aug 2012 14:01:48 +0000

Ye. It’s one of the rules from “Effective Java”. Classes with mutable instance variables should copy them both on input and on output. Otherwise a malicious programmer could break your objects. Suppose DtaeRange had vanilla getters and setters. Consider code like

Date today = new Date();
Date tomorrow = …; // code omitted.
DateRange range = new DateRange(today, tomorrow);
// Assume DateRange checks that start is before end.
today.setTime(aLongRepresentingNextYear);
//Since DateRange did not copy start,
// range.start is now after range.end.

As Effective Java said, don’t use clone() to copy the dates on input either. Somebody might give a preverse subclass of Date. In fact try to read and memorize that book.

Best is to use immutable objects as much as possible. Use the Joda-Time library instead of java.util.Date, for example. Use the offical replacement Date library when Java 8 or 9 eventually adds it

By: Rogerio

Rogerio — Thu, 09 Aug 2012 13:11:05 +0000

I am not sure about always using a message for each assertion…

In practice, it is hardly useful because you still need to open the test method in your IDE, run it to confirm the failure, apply a fix, then run the test again to confirm it now passes. Just reading the error message (plus the test name) is usually not enough to understand what the test is about or why it failed. You actually need to look at the test as a whole to achieve that, and having that message or not will often not make any real difference. Not to mention that such messages can easily be poorly written or misleading. At least, this has been my experience.

By: jenslukowski

jenslukowski — Thu, 09 Aug 2012 09:19:07 +0000

If I understand you correctly, you mean that a setter should make a copy of its passed value and the test should test for this. That’s another good aspect. Thank you

By: jenslukowski

jenslukowski — Thu, 09 Aug 2012 09:14:08 +0000

Yes, thank you.
The patterns where extracted from (old) JUnit3 tests, so the solution could be made even better when using JUnit4.

By: jenslukowski

jenslukowski — Thu, 09 Aug 2012 09:11:16 +0000

Yep

By: jenslukowski

jenslukowski — Thu, 09 Aug 2012 09:09:56 +0000

You are right, thank you, missed out on that one, Updated the post accordingly.

By: Mike

Mike — Thu, 09 Aug 2012 02:22:27 +0000

So… in summary: Always use a message. Enable assertions. Don’t have multiple code paths in a test.

By: Lars Briem

Lars Briem — Wed, 08 Aug 2012 20:15:25 +0000

Thanks for this nice article on some antipatterns of unit tests, but I think there are two little mistakes in the last solution of the exception example:

try {
callFailingMethod()
} catch (ParseException e) {
fail(“Invalid character at line 2″, e.getMessage())
}

The first one is, that you use the “fail” method to compare the two messages. I think this should be an “asserEquals” call, shouldn’t it?
So I think it should be like this:

try {
callFailingMethod()
} catch (ParseException e) {
assertEquals(“Invalid character at line 2″, e.getMessage())
}

The other one is, a bit difficult because I do not know if I understand the code correct.
In my opinion you want to test that the “callFailingMethod” throws an exception. But your test will also pass if no exception is thrown. For this case the “fail” call after the “callFailingMethod” is necessary and can not be removed.
So my final solution looks like this:

try {
callFailingMethod()
fail(“ParseException should be thrown.”)
} catch (ParseException e) {
assertEquals(“Invalid character at line 2″, e.getMessage())
}

Am I right or do I miss something?