Michael Schubart's Weblog

Itoki Building, Chuo-ku, Tokyo.

Here’s a neat idea: Jester is a tool that randomly introduces bugs to your production code (a copy of the code, of course). Then it runs your unit tests to see if they fail. They should - and if they don’t, you might want to add some more unit tests in order to get better coverage.

This is an alternative to using a code coverage tool in order to test your tests. In fact, it might even be more effective than code coverage because code coverage only tells you whether a line of code has been executed or not. It does not help you understand the quality of the tests. Here’s an example:

Let’s say we have the following production code:

public static int maximum(int x, int y) {
    if (x > y) {
        return x;
    } else {
        return x; // Bug: Should return y.
    }
}

And we have the following “test”:

public void testMaximumA() {
    MyMath.maximum(4, 3);
}

If we run this test using a code coverage tool, the tool will tell us: “50% coverage”. Not too bad, but the test did not catch the bug. Hm, maybe 50% is just not enough. Looking at the output of the coverage tool, we see that the “else” statement is never executed. That makes sense: We don’t have a test where the y parameter is the maximum. Let’s add this case:

public void testMaximumB() {
    MyMath.maximum(4, 3);
    MyMath.maximum(10, 22);
}

Now the code coverage tool tells us that we have achieved 100% code coverage. Perfect! But the test still does not catch the bug. Let’s use Jester. Jester randomly introduces a bug. For example, it might turn the “greater than” into a “less than”:

public static int maximum(int x, int y) {
    if (x < y) { //Bug introduced by Jester. Was: (x > y)
        return x;
    } else {
        return x; // Bug: Should return y.
    }
}

When we next run the unit tests, they will still pass. And Jester will say: “Hey, I just broke your code. How come your unit tests still pass? The test of the tests has failed!” So Jester has found a problem that the code coverage tool could not detect. Note that we did not (directly) find the bug in the production code. We only found an issue with the tests. Once we improve the tests, they will hopefully reveal the actual bug. Let’s do that, just to be complete:

public void testMaximumB() {
    assertEquals(4, MyMath.maximum(4, 3));
    assertEquals(22, MyMath.maximum(10, 22));
}

A very original and elegant concept!

I found Jester via IBM developerWorks - in spite of their awful RSS feeds…

The meeting has been postponed. I’ll post an update once I know the new date.

From the NinJava (the Tokyo Java users group) mailing list:

Our next meeting is scheduled for Thursday, February 24th, 2005 from 7:00 to 9:00 PM.

We’re meeting again at Temple University. See below for details.

********** MEETING AGENDA **********

The meeting’s agenda is as follows:

7:00 - 7:15 PM Networking and Setup
7:15 - 8:15 PM A quick look at Tapestry by Nick Westgate

Tapestry is a powerful, open-source, all-Java framework for creating leading edge web applications in Java.

Tapestry is an alternative to scripting environments such as JavaServer Pages or Velocity. Tapestry goes far further, providing a complete framework for creating extremely dynamic applications with minimal amounts of coding.

Nick will give a quick introduction to Tapestry concentrating on the key points you need to know to use it and will show a basic Tapestry web application demonstrating the advantages of using Tapestry.

Bio:
Nick Westgate (BSc) currently writes telephony and web applications in Delphi and Java for KEY Planning (Japan). In previous lives, he has developed multi-threaded C++ client/server software for Pharos Systems (New Zealand) and ‘edutainment’ software in C and assembler.

8:30 - 9:00 PM Open Discussion

———–LOCATION———–

On the fifth floor, room 502.

This URL has access info for TUJ:
http://www.tuj.ac.jp/newsite/main/maps/index.html

Hosted by the Temple IT Program at Temple University Japan.
For more information see http://www.tuj.ac.jp/itp/

I’ve used Tapestry before: It’s a very elegant web application framework for Java. Using Tapestry felt like a breath of fresh air after cobbling together a web app with Struts and JSP. I can also recommend the book Tapestry in Action by Howard Lewis Ship, the creator of Tapestry.

Seen in Sydney.

Seen in Launceston, Australia.

I uploaded some of my photos to Flickr (I especially like the squared circle and Spiral Mandala groups.) Flickr lets you view the EXIF data of pictures. Browsing through this metadata, I found an item “Total Number of Shutter Releases for Camera” — Is this the total number of pictures I’ve taken so far with this camera? That’s a little bit more information than I really care to broadcast to the Internet. But then again, I’ll probably be too lazy to do anything about it.

Does anbody know if it’s possible to reset this counter? It might also be an interesting item to check when buying a used camera.

Or — imagine the counter went down, not up, and when it’s 0, you’d have to buy a new camera… Which reminds me of this idea I had as a kid: I tried to imagine living in a world where everybody could only speak a fixed number of words in their lives. After using up all of your words you’d have to stay silent until you die. People in this world would try to stockpile their words and only speak on special occasions. Saying something nice to someone you like would be a real gift because you’d have to “spend” some of your precious words!

Weird world to live in, eh? I think there’s a lesson to be learned here: Watch your metadata!

My apartment is right by the Sumidawa River. Randomly searching Google Images for “Sumidagawa”, I discovered this site with nice diagrams and vital statistics of all Sumidagawa bridges in Tokyo. The site owner seems to be some kind of bridge geek.