codesmell.org

You do test-driven development? Yeah, right. Everyone does nowadays. But do you really ?
Fear not. I wont get into the discussion of what testcases are and what they can be used for. But if you happen to really code test-driven, then what is your coverage? You don’t know? You should! Until this morning i thought measuring code coverage is a tedious, bad performing, html-report-only step in a good (in the academic sense) maven configuration.

Reason for these lines: I just found out, that code coverage can be fun, quite performing, and really easy to use!
If you’re familiar with the concept of measuring coverage, you can just skip the rest of this article and target your browser to
eclemma .

Suppose this (overly stupid) class:

public class Foo
{
    static final String CLOSE_BUT_LITTLE_TOO_HIGH = "close but little too high";
    static final String CLOSE_BUT_LITTLE_TOO_LOW = "close but little too low";
    static final String YOU_WIN = "YOU WIN";
    static final String MUCH_TOO_HIGH = "much too high";
    static final String MUCH_TOO_LOW = "much too low";

    String halo16(final int i)
    {
        if (i < 10)
        {
            return Foo.MUCH_TOO_LOW;
        }
        if (i > 20)
        {
            return Foo.MUCH_TOO_HIGH;
        }
        if (i == 16)
        {
            return Foo.YOU_WIN;
        }
        return i < 16 ? Foo.CLOSE_BUT_LITTLE_TOO_LOW : Foo.CLOSE_BUT_LITTLE_TOO_HIGH;
    }
}

and its test counterpart

FooTest.java

                    import junit.framework.TestCase;

public class FooTest extends TestCase
{
    public void testFoo()
    {
        final Foo foo = new Foo();
        assertEquals(Foo.MUCH_TOO_LOW, foo.halo16(9));
    }
}

Any blind coder can see, that we tested only a fragment of the functionality provided by method halo16().
The point is, you never really know if you covered any execution path possible. You can now argue that this situation is not going to happen if really using test-first approach (which sounds correct), but we all know that software is going to be maintained, refactored, featuredecorated aso. So be sure, you’ll run into this. Now what eclemma does is to monitor the execution paths during test-run within eclipse and directly decorate your source with the determined results:

Obviously, red means: not executed. So by adding

FooTest.java

                    assertEquals(Foo.MUCH_TOO_HIGH, foo.halo16(21));
                    assertEquals(Foo.YOU_WIN, foo.halo16(16));
                    assertEquals(Foo.CLOSE_BUT_LITTLE_TOO_LOW, foo.halo16(15));

you’ll get:

which even gives you the info that the last line is only covered partially, which makes you add

FooTest.java

                    assertEquals(Foo.CLOSE_BUT_LITTLE_TOO_HIGH, foo.halo16(17));

in order to get things completely green as well as a good night’s sleep.
That’s what i call a very nice eclipse plugin.

Get it here .