私は最近コードカバレッジツール（特にEmmaとEclEmma）を使い始めましたが、単体テストの完全性と、単体テストがコードのどの領域にないかを確認できるという見方が本当に気に入っています。まったくヒットしません。私は現在、単体テストをあまり行わない組織で働いています。私は、すべての人に単体テストとコードカバレッジ、およびTDDを実施し、できれば組織を変換するように促す予定です。
このテーマについて私が確信していない問題の1つは、コードカバレッジをどこまで実行する必要があるかということです。たとえば、次のようなクラスがある場合：
//this class is meant as a pseudo-enum - I'm stuck on Java 1.4 for time being
public final class BillingUnit {
public final static BillingUnit MONTH = new BillingUnit("month");
public final static BillingUnit YEAR = new BillingUnit("year");
private String value;
private BillingUnit(String value) {
this.value = value;
}
public String getValue() {
return this.value;
}
public boolean equals(Object obj) {
return value.equals(((BillingUnit) obj).getValue());
}
public int hashCode() {
return value.hashCode();
}
}
equals()正しく機能すること、期待どおりの結果が得られることなどを確認するために、いくつかの簡単な単体テストを作成しgetValue()ました。しかし、EclEmmaの視覚的な性質のおかげで、hashcode()メソッドは「テストされていない」場合は明るい赤で表示されます。
hashCode()この例では、実装がいかに簡単であるかを考えると、わざわざテストする価値がありますか？このメソッドの単体テストを追加して、コードカバレッジを％向上させ、EclEmmaがこれらの行に追加する明白な赤いハイライトを取り除くように感じます。
神経症でOCDに似ているかもしれませんが、EclEmmaのようなものを使用すると、テストされていないものを簡単に確認できます。プラグインはソースコードを赤で強調表示し、カバーされたコードは緑で強調表示します。できるだけ多くのクラスを100％グリーンにするようにプッシュします-それがあまりメリットをもたらさない場合でも。