自分の神経質なところ

　私は、決してまめなほうじゃないんです。むしろずぼら。ですが、ことコーディング等においては神経質なんですよ。

　たとえば、インスタンス化することがないユーティリティクラス HogeUtils を作るとします。そうすると、以下のようにコンストラクタはプライベートにしないと気がすみません。

public class HogeUtils {
    private HogeUtils() {
        // 何もしない
    }

    // 以下略
}

　それで、神経質なので、こんなんでもカバレッジ率を100％にしたいので、テストは以下のように書いたりします。

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;

import java.lang.reflect.Constructor;

import org.junit.Test;

public class HogeUtilsTest {
    @Test
    public testHogeUtils() throws Exception {
        Constructor<?>[] constructors = HogeUtils.class.getDeclaredConstructors();
        // コンストラクタがひとつしかないことを確認
        assertEquals(1, constructors.length);
        // それがアクセス不可であることを確認
        assertFalse(constructors[0].isAccessible());

        // カバレッジ率を上げるためだけの処理
        constructors[0].setAccessible(true);
        constructors[0].newInstance();
    }

    // 以下略
}

　正直、無駄だなぁと思うこともありますが、規模が大きくなってくると、カバレッジ率が100％でない場合「なぜだぁ！どこだぁ！」とよく騒ぐ羽目になります（規模が小さいならそれを覚えていられるからまだ良い）ので、あながち無駄でもないのかなとも思います。あまりにもカバレッジ率が100％に行ってないと、カバレッジテストが狼少年化するので。たとえば、ほんとうに「漏れ」てるのによく検証もしないで「あ、そこはもともと100％ならないから」なんて安易に判断してしまったりしてしまうことがないともいえません。

　ただ、問題は、まず起こらない例外の扱いですね。たとえば以下のようなコードです。

    public String toString(byte[] bytes) {
        try {
            return new String(bytes, "UTF-8");
        } catch (UnsupportedEncodingException e) {
            // ここに来ることはまずない
        }
    }

　こういった場合、私は、このような部分だけサブプロジェクトにしてしまいます。たいていの場合、このような振る舞いをするところは横断的関心事（Cross-cutting Concern）ですので。コンパクトなサブプロジェクトならばカバレッジ率が100％にならなくても管理しやすいというわけです。