参考書籍は Test Driven Development By Example [ Kent Beck ]、 日本語版は テスト駆動開発入門です。
今回はテストのエッセンスについてです。 テストを書いて、実装コードを書き、機能追加していく中で需要なポイントを拾って書きました。 テスト駆動開発でテストを先に書く手順の続きになります。
Assert を先に書く
テストを書くときは Assert から書くのがいいそうです。 確かに、 ゴールから決めるのは常套手段ですね。
Assert から始めるに当たって、 まず考えるのは次の2つです。
- What is the right answer? (どうなったら正しいといえるのか)
- How am I going to check? (どうやってチェックするのか、何の値をチェックするのか)
本書に載っている例を見ると、 上の2点から始めて Assert 部分 から 存在しないクラスを使ってテストを書き始め、 最終的にテストを完成させているのがよくわかります。
テストデータ
Kent Beck によれば テストにおいて使用するデータにも鉄則があります。 わかりやすいもの、 すなわち 1 でも 2 でもよいのなら 1 を使うんだとか。
またシステムによっては 実データをテストに使うこともあると思いますが、 Kent Beck は実データは特に次のようなケースで有効であると述べています。
- 実稼働している他のシステムで出力されたデータを使うリアルタイムシステムのテストをする場合。
- 変更前のプログラムと変更後のプログラムによる出力を比較する場合。
特に難しい話ではありませんが、 一旦整理して頭に入れておきましょう。
テストの実装ルール
テストコードは一般的なプログラミングルールを逸脱することがあります。 例えばマジックナンバー。 というのも、 テストにおいては実装コードを完成させることと テストによるフィードバックを必要なだけ得られるようにするのが目的だからです。 MONEY EXAMPLE
の章でもありましたが、 まずマジックナンバーを使うことで ひとまずのテストを完成させていました。
もういちど MONEY EXAMPLE
の章で列挙されていた方法について説明されています。 Fake It
と Triangulation
がありますが、 一番最初におさえないといけないのは Fake It
です。
Fake It (‘Til You Make It)
英語版102ページでは python でテストフレームワークを作っていたときの実例が紹介されています。 テストコードが Fake からどんどん変わっていく部分が再掲されています。
Kent Beck は Fake It
のメリットとして次の2つを挙げています。 2つめのは 少し前のページにも出てきていました。
- まずテストをグリーンにすることでコードに確信がもてる。 余計な心配をしなくていい。
- わかりきったものでもテストを書いてグリーンにしておくことで、 今どの機能が足りていないかをわかりやすくする。
そこから Triangulation
の話へと続きます。 内容は MONEY EXAMPLE
で出てきた話の復習です。 復習なので割愛します。
パラメータを増やす場合
テストが完成した後で機能を追加する例として sum(int value) から sum(int[] values) へ書き換えるときのテストコードの書き方が載っています。 もちろん説明用に作られたメソッドなので不自然なところもありますが、 流れは一通り覚えておきたいですね。
同僚の勧めで 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
