第4章 意図を語るテスト
本章でやったこと
TDD で立ち向かうべきリスクの認識
上記のリスクを受け入れた上で意図を語るにテストへ改善
副次的にテストコードと本番コードの 結合度 も低下 意図を語るテスト
現状のテストケースは 「$5 の 2 倍にすると、amount フィールドは 10 である」と読める
code:java
@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);
}
これだと、times が Dollar を返すとは分かりづらい
変数宣言してるし、分かるとは思うけど… radish-miyazaki.icon
これを以下のようにすると、「$5 の 2 倍は $10 である」と読め、より意図が明確になる
ここで第 3 章で実装した equals を用いている
これにより後述するリスクが発生するが、これは許容
code:java
public void testMultiplication() {
Dollar five = new Dollar(5);
assertEquals(new Dollar(10), five.times(2));
assertEquals(new Dollar(15), five.times(3));
}
TDD で立ち向かうべきリスク
正しく検証できていないテストがあったら、どうしようもない
e.g. 等価性比較が正確に実装されていることが検証されていないならば、掛け算が正確に実装されていることは検証できない
実際、第3章では null や他のオブジェクトの等価性比較は未検証
これは TDD で受け入れるべきリスク
本章ではこれを受け入れ、テストコードで利用した
TDD は 完璧な正しさの保証ではなく、十分な自信を素早く得るための実践的手法