テスト駆動開発 › 意図を語るテスト

TL;DR

• 第 3 章で実装した equals を使い、テストを「$5 の 2 倍は $10 である」と読める形に書き直した。副次的に、テストコードと本番コードの結合度も下がった。
• equals が十分に検証されていないというリスクは残るが、TDD はそれを受け入れる。

内容

意図を語るテスト

それまでのテストは「$5 を 2 倍すると、amount フィールドは 10 である」と読める。これでは、times が Dollar を返すことが分かりにくい。

@Test
public void testMultiplication() {
    Dollar five = new Dollar(5);
    Dollar product = five.times(2);
    assertEquals(10, product.amount);
    product = five.times(3);
    assertEquals(15, product.amount);
}

第 3 章で実装した equals を使って次のように書き直すと、「$5 の 2 倍は $10 である」と読め、意図が明確になる。

@Test
public void testMultiplication() {
    Dollar five = new Dollar(5);
    assertEquals(new Dollar(10), five.times(2));
    assertEquals(new Dollar(15), five.times(3));
}

TDD で受け入れるリスク

正しく検証できていないテストがあると、どうしようもない。たとえば、等価性比較が正しく実装されていることを検証していなければ、それを使う掛け算のテストも正しさを保証できない。実際、第 3 章では null や他のオブジェクトとの等価性比較を検証していない。

これは TDD で受け入れるべきリスクであり、本章ではそれを受け入れて equals をテストコードで使った。TDD は完璧な正しさを保証するものではなく、十分な自信を素早く得るための実践的な手法である。

キーワード

• テスト駆動開発
• 結合度

自分の理解

書き直す前のテストでも、変数を Dollar 型で宣言しているので、times が Dollar を返すことはそれなりに分かるとは思う。