目次
参考書籍は 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) へ書き換えるときのテストコードの書き方が載っています。 もちろん説明用に作られたメソッドなので不自然なところもありますが、 流れは一通り覚えておきたいですね。
