Thursday August 17, 2006

A Longtime Java ME Guy

This entry is a response to an entry on Anet's blog, Time to come out of the closet.

Not as long as Anet, but perhaps almost as long. I got involved with Java ME (really, the precursor to Java ME) about seven years ago, back when KVM was the next big thing and MIDP hadn't even been started yet. I did some work with NTT DoCoMo, I was on the MIDP 1.0 and 2.0 expert groups, and I've done a lot of work on Sun's products in this area.

Now plans have been announced to open-source Java ME. Time to strap in and hit the throttle!

Tests have a better memory than you do

My past several blog entries have been about testing, more precisely about unit testing or test-driven development. I suppose I should talk about how I got started on all of this.

Up until few years ago, I developed code in a "conventional" style, that is, without unit tests. I kept hearing about unit testing and test-driven development but I didn't know what to make of it. I read a couple articles and it seemed sorta weird, but I didn't really catch on. But, as my experience shows, you can't catch on to something just by reading about it. You have to do something and experience it.

So, I decided that when I next had a couple spare hours free (naturally, this was a major source of delay) I assigned myself a simple programming task. The actual task isn't relevant, but it was simple enough that I could implement something of interesting complexity within a few minutes and then add features incrementally.

But I did eventually get the time to do this. I downloaded JUnit from junit.org and followed the procedure of writing the test for the code before writing the actual code. I felt really stupid at first. I couldn't even compile the test, since I hadn't written any code yet, not even a stub! But I kept going: I added the code, and then the test passed. I added another test (which failed, of course) and then I added the code to make the test pass. And so forth. I even started taking shortcuts by writing the test and the code at the same time. It's not strictly by the book, but what-the-heck. After a while, I had a couple hundred lines of code and a dozen or so unit tests. Things were going pretty smoothly.

But then something really interesting happened. I had implemented features A, B, C, and D and their corresponding unit tests. I added a test for feature E and then code to implement feature E. I ran the tests, and the test for the new feature E passed. But the test for feature B failed!

This came as quite a surprise to me. After programming for only a couple hours, and with only a couple hundred lines of code, my unit tests knew more about my code than I did. When I implemented feature E, I thought it would work -- and it did -- but I also thought that it wouldn't break anything else. I was wrong. It just goes to show that your unit tests have a better memory than you do.

I've been test infected ever since.