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 です。

パラメータを増やす場合

テストが完成した後で機能を追加する例として sum(int value) から sum(int[] values) へ書き換えるときのテストコードの書き方が載っています。 もちろん説明用に作られたメソッドなので不自然なところもありますが、 流れは一通り覚えておきたいですね。