参考書籍は Test-Driven Development By Example、 日本語版は テスト駆動開発入門です。
機能追加の方針
Franc-ly Speaking
のところ(29ページ)からです。 Franc を導入して複数通貨に対応させるんですね。 39ページに至るまでの流れを見ていくと次のようになります。
Dollarを複製する。 テストコードも複製する。- 親クラス
Moneyと 継承クラスDollar,Francに分ける。 - Factory Method Pattern で
Moneyクラス に共通のものを集約する。
Dollar から Money へ、 子クラスから親クラスへメソッドを移す手順には要注意ですね。
書かないテスト
途中、 toString() というメソッドを、テストコードを書かずに追加しています。 この判断基準は重要なのでまとめておきます。
次の条件を満たす場合は、テストコードを書かなくてもOKとします。
- 画面上で(テストの)結果を見ようとするメソッドを追加しようとしている。
- 追加するコードはデバッグのためのコードで、仮に正常に動かなくなったとしてもダメージが小さい。
- テストが Red で終了している。 (Red のときは新しいテストコードを書きたくない。)
普遍的にまとめた記述が今のところ出てきていないので toString() 追加の際の説明をまとめたものになっています。
toString() 程度 だったらテストを書いてもよさそうですが、 もっと複雑なものに成った場合には テストを書かずに進めた方がいいんでしょうか。 これは実践あるのみですね。
その後 Money Example
の演算の実装と、 全体を俯瞰した傾向、 テストの品質について重要な記述がありますが、 ひとつひとつ紹介すると長くなるので割愛します。 でもひとつだけ気になる記述があるので紹介します。
Easy to read for programmers – Unsynchronized documentation is scarce. The tests will be more valuable if they are readable, giving an interesting second perspective on the messages hidden in the source code.
テストを書けば仕様も理解しやすくなるかもしれないと思いました。
