参考書籍は 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.
テストを書けば仕様も理解しやすくなるかもしれないと思いました。
同僚の勧めで Test-Driven Development By Example を読むことにしました。 書いたのはあの Kent Beck です。 日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。
この本では具体例が示されていて、どのようにテストができていき どのようにコードができていくのかがよくわかります。 まだ最初のほうしか読んでいませんが、他人(Kent Beck)のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。
Test Driven の基本
Preface のところに Test Driven の基本ルールが書いてあります。
- 自動テストに失敗するまで新しいコードを書かない。
- 重複は排除する。
テストで失敗するまでコードを書いてはいけません。 これに関連して よくはまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。 これについて 同僚は次のような説明をしてくれました。
自動テストがないときはどうやってテストしていましたか？ (PHPの場合) var_dump などでテストをしていたと思います。 テストコードのテストコードというのは、 その var_dump と 目視 のテストを書くってことと同じことなんですよ。 テストコードそのものの正しさは開発者が担保するようにして進めるんです。
わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。 またテストコードのバグについてはじゃんじゃん直していいそうです。
そして Kent Beck はコードの書き方について重要な方針を書いています。
自分の書いたコードのテストは自分で書こう
これ重要ですね。 この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。 Red / Green / Refactor の順でやろうと思ったら自分で書くしかないんですけどね。
テスト駆動・自動テストのメリット
開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。 地位の高い人がそういうことを言い出すとどうしようもなくなったりします。 モチベーションにも繋がるところなので 自動テストのメリットを再確認しましょう。 本書では social implications として4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。
- 汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。
- 自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。
- ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。
- 開発者のみならずマネージャにとっても嬉しいことが起こります。
- 技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。
- 開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。
- 汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。
- 毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。
特に2番目は重要ポイントですね、 テストドリブンとは関係なさそうな人にもメリットがもたらされるので。 どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。
この本を読んで今以上にテストドリブンに力を入れていこうと思いました。 中にはテストを書かない人もいるのですが、具体的な進め方も書いてある本なので 他人への説明も楽にできると思っています。
A Life Summary of an Gypsy
