And another thing

I actually prefer a unit test to a type system hierarchy. That’s the tester coming out for sure.

If a foo can do something with a object of type bar or baz but not a quux, how do test that:

class Foo
public Fooible get() { return lookupAndInstantiate(“object_id”); }
class Bar implements Fooible {}
class Baz implements Fooible {}
class Quuz {} //does not implement Fooible

assert(foo.get(id_of_a_bar) instanceof Fooible);
assert(foo.get(id_of_a_baz) instanceof Foobile);
assert(! foo.get(id_of_a_quux) instanceof Foobile);

I want to do this, but my compiler prevents me from testing it. I could cast, but that’d be pointless. I could build an ugly mock that has no point other than to get around the type system, but still not good.

I’m going to score 1 for dynamic languages, because in the real world, you end up getting Quuxes, especially if you want to use something like ActiveRecord; and you’ll write a lot of code to prevent it and a lot of code to get around those compiler checks, otherwise.

A simple junit rant

I’m going to make this very simple. My last junit rant (online — I think on 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.


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.