Isolated Test

Test の独立性についてですが、 Kent Beck は過去の経験から次のように綴っています。

First, make the tests so fast to run that I can run them myself, and run them often. That way I can catch errors before anyone else sees them, and I don’t have to dread coming in in the morning. Second, I noticed after a while that a huge stack of paper didn’t usually mean a huge list of problems. More often it meant that one test had broken early, leaving the system in an unpredictable state for the next test.

続けて書かれていますが、 ひとつの問題が発生した場合に失敗するテストはひとつであるべきです。 問題の特定を楽にするために。

そんな独立性の高いテストを作る手頃な方法として、 “実行順序に依存しないテスト” が挙げられていますね。

テストを書く前に ToDo List

Kent Beck は彼の経験から、 目的を達成するためには (プログラムで実現すべきことを実現するためには) やることを全部書き出すというのがいい と結論づけています。 Money Example の中でも ToDo List を作っていました。

ToDo List のメンテナンスにも注意が必要です。 Kent Beck は新しい ToDo が増えたとき、 既存の ToDo 含め 次の3つのカテゴリに分けます。

• いまやる
• あとでやる
• できなくてもいい

テスト駆動開発において ToDo List に書かれるのは Test として実装するべき事項です。 具体的には Section I の Money Example に載っていたものです。

なぜテストを先に書くのか

Kent Beck はテストを先に書く理由について、 次のように書いています。

• コードを書くプログラマとしてのゴールは機能追加であってテストを書くことではないため、実装の後(目的達成後)にテストコードを書くことはない。 (目的達成後にテストを書こうと思わない。)
• (コードの)デザインについて考える時間が必要。
• スコープを制御するためのメソッドが必要。 ここでいうスコープは、後のページで詳しく説明が出てくるが、要するにテストを順次グリーンにして、今実装すべき機能(スコープ)を整理するということ。

確かに、 実装が先に終わってテストがおまけになってしまう、 そんな経験が多々あります。 更に Kent Beck は テストのモチベーションのサイクルについても言及しています。 テストのモチベーションは開発者にとって一番大事かもしれません。