[Previous entry: "All right... so it wasn't a FitNesse bug"] [Next entry: "Painting the floor"]

11/16/2005: "Why I don't care about 100% code coverage"

On the JUnit Yahoo! group, someone asked me:

I am on the other side of the shore and believe in Code coverage and so very interested in knowing why you feel that 100% code coverage isn't a requirement for code check in? Can you please share your thoughts?

Sure: 100% line/branch coverage is impossible to achieve. Even if it were possible, it's not worth the effort. Example:

JDBC driver throws SQLException, which is checked. In my code, I have to do this:

try {
    useJdbcDriver();
}
catch (SQLException e) {
    // What to do here?
}

Well, my default checked exception handler is this:

try {
    useJdbcDriver();
}
catch (SQLException wrapped) {
    throw new RuntimeException(
        "Something went wrong when I used the database", wrapped);
}

There are two problems with this:

1. It takes an obscene amount of effort to simulate (or recreate) the conditions under which the JDBC driver throws an SQLException.

   The vast, vast majority of the time, I don't handle those exceptions anyway, but rather pass them up the chain. To avoid coupling myself to my caller, I turn the checked exception into an unchecked one.

2. Java forces me to duplicate that exception handler everywhere throughout my code, although I could get a little better with

       ExceptionHandler.shush(
           "Something went wrong when I used the database", shushed);
   

   Still, I have to duplicate that everywhere, but I certainly don't need to test it everywhere I use it. The only thing that changes is the explanation message, and I never write code that depends on that text in any meaningful way.

Both of these make it unusually expensive to test-drive this code, compared to the benefit I get from test-driving it. As a result, I have judged that it's not worth the effort, so I don't do it.