A simple junit rant

I’m going to make this very simple. My last junit rant (online — I think on theserverside.com) resulted in a nice email from Cedric Beust about this new thing he was working on called testNG. Oh how I wish I could use it at work. Luckily, that will be an option in 3 days, as I will retire and work for myself full time. JUnit 4 has been a blessing over 3, though dependencies and useful annotations are still sorely missed. @BeforeClass is also mostly verboten, but is allowed in special cases when it shouldn’t be used!

Anyway, this is a very simple rant, though I’m very curious about how I uncovered it.

No assertNotEquals() yet!?!

I’ve wasted time trying to find a rationale. Of course, I have found the junit addons package, but I’m not going to force my employer into that dependency. Maybe I’m missing something, but this is probably the most valid unit test. The likelihood of two things being equal when you expect them to is pretty high, and the likelihood of something being true when you expect it to is even higher. What you really want to know is when something isn’t true (not difficult, even without assertFalse(), which for some reason is religiously implemented) or more especially when two values aren’t equal.

Roundoff errors immediately come to mind, and are an ideal candidate for the architypical unit test. Date handling is another example, and string munging also makes sense. So would image manipulation, though Java isn’t a good language for that.

Anyway, how I came across this, and I’m probably just stupid, is with temperature conversions. Here’s my test that I would expect to fail:

Temperature t = new Temperature(-40.0, ‘F’);
assertEquals(-40.1f, t.convert());

And here’s the code that is being exercised:

public float convert()
{
if (scale == ‘F’) { return 5 * (temp – 32) / 9; }
else if (scale == ‘C’) { return (9 * temp / 5) + 32; }
else { throw new RuntimeException (“unknown temperature scale”);
}

Maybe I’ve spent too much time in scripting languages that do a better job of casting or something. Anyway, it’s not a big issue what’s causing my bug, but I want my test to uncover it.

NOTES:

1 – It looks like there is no assertEquals(float, float.) So it is calling assertEquals(Object, Object). Behind the scenes is it treating them as doubles, integers, or strings?

1.5 – It looks like assertNotSame() will do the trick for this particular case. Is this the answer to checking round off errors? Still, it wouldn’t work on more complex arrangements, or on bit arrays (images), right? I guess it’s fair to write your own assert for comparing images, but surely someone’s done it before.

2 – It also looks like TestNG doesn’t have assertNotEquals either. I’ll probably get another note from Cedric that it was added to and and released yesterday or something.

I admit I was a bit star struck and felt ahead of the curve too that someone with reputation responded to my message. I should start a geek celebrity sighting scrapbook. I still remember when Havoc Pennington responded to an simple question about Metacity code. He dismissed it at the time as a pet project he’d abandoned and then a year or two later it got adopted as Redhat’s default X window manager. I seriously doubt my asinine patch was ever included. But I’ve got (or had) code in docuwiki. I wanted prettier table layouts and hacked a few features into it. I think that was the point I realized that I thought I could really code, submitting a patch and getting it listed on the release notes.

About these ads

4 thoughts on “A simple junit rant

  1. How is AssertNotEquals different from:

    AssertEquals(false,( a == b) );
    AssertEquals(true,(a != b) );
    AssertFalse((a == b));
    AssertTrue((a != b));
    AssertFalse(“a isn’t b”,(a == b));
    AssertTrue(“a not b”,(a != b));

    • The difference is pretty obvious:
      Your suggestions just throw an AssertionFailedError without the reason it failed (“expected but was “), hence unfortunately not very useful.

  2. Because if you’re dumb, like me, it isn’t obvious until someone points it out. I’ve been trying to think of an operation where an equality test wont work, but for any of those, you’d need an overridden method anyway.

    I’ll shut up now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s