TDDについて
インターンのプラクティスにてTDDについて学習。
TDDについては、「Test-Driven Development の略である」ぐらいの認識からスタートして色々調べて今のところ自分でわかっている範囲でメモ。
ところどころ勘違いが含まれてる可能性もあるので要注意です。
TDDの３ステップ
TDDの根幹となる３つのステップはだいたいこんな感じであった。
- 今から実装する機能に対するテストを１つ書き、テストが失敗することを確認する。(レッド)
- 先ほど失敗したテストを通すための最低限のコードを実装する。(グリーン)
- 成功したコードをより洗練されたものにする。(リファクタリング)
各ステップのポイント
- ステップ1のポイント
- 開発者自身がテストを書く。
- テストはたくさん書くのではなく、必ず１つ。
- テストが失敗することの確認を怠らない。
- ステップ2のポイント
- 機能が実際に動作するところまでもっていく。
- この時点では、コードの再利用性や設計の美醜を気にせず、テストが通ればなんでもいい。
- ステップ3のポイント
- 外部から見た振る舞いを維持しつつ、コード内部の設計を洗練していく。
「テスト」が指す意味
ここまでテストという言葉を連発してきたが、一体どういうテストなのか。 TDDにおける「テスト」の意味を再確認する必要がある。
一般的に言われるテストには大きく分けて、３つの分類がある。
- Development Test (開発促進設計行為)
- 開発者自身が開発者やチームの為に行うテスト。
- 開発を前に進めるためのテスト。
- Customer Test (進捗管理機能要件)
- 客から見て機能がどれほど進んでいるか確認するためのテスト。
- このテストが通らない限り、当該機能はできあがっていないと見なす。
- Quality Assurance Test (品質保証非機能要件)
- 品質管理、品質保証の側面からのテスト。
- 様々な切り口から、ソフトウェアの信頼性を上げるために行われるテスト。
この内、TDDにおける「テスト」とは Development Test のことを指す。
実際のサイクル
まず「受け入れテスト」を書く。つまり、プログラムの実装がどうなっているかを度外視して、「こうなるべき」「こうなってほしい」という視点のテスト書く。これを「ブラックボックステスト」と呼ぶ。
- End-to-End のテストであることに注意。例えば、リクエストを送ってレスポンスを受けるという部分のみに着目し、サーバ側の細かい役割についてはブラックボックスとして扱うようなテストのこと。
- ここでの「受け入れテスト」は、「開発者がこれから開発するために行うという」視点なのでCustomer Test ではなく、 Development Test に分類されることに注意。
次に「受け入れテスト」を通すために、テストリストを作成し、ToDoを抽出する。
テストリストの一つ一つに対して実際にテストを書いていく。テストコードを先に書くことをテストファーストと呼ぶ、
ポイント
- TDDは「自己相似構造」。大きい輪の中の小さい輪、つまり「受け入れテスト」の中の「機能の各部分のテスト」を一つ一つTDDで、レッド、グリーンの円環構造で回していくうちに、「受け入れテスト」がレッドからグリーンになるという構造。
- テストの最小単位は「不安」。不安を感じたらテストすればいい。
参考URL
http://gihyo.jp/dev/serial/01/tdd/0001
http://www.slideshare.net/shuji_w6e/ss-30692945
