TDD（テスト駆動開発）
TDDとは、テストファーストとリファクタリングという2つのプラクティスを組み合わせて実施するプログラミング技法です。
TDD ＝ テストファースト ＋ リファクタリング
名称に「開発」と入っていますが、実際にはいわゆる実装工程で利用する技法です。TDDによって「実装時間が2割増えるが、バグは半減する」と言われています※1。
テストファーストは、まずこれから実装するメソッドなどのスペック（外部設計※2）を自動実行できるテストケースとして表現し、次にそのテストケースを満たすように目的のメソッドなど（製品コード）を書く（内部設計）というプラクティスです。
テストファースト： 外部設計（テストケース） → 内部設計（製品コード）※3
テストファーストでは、1つテストケースを書いた時点で一度テストを実行して、それが失敗することを確認します。これから実装しようとしている製品コードが、間違いなくまだ実装されていないことを確認するわけです。それから実際に製品コードを書き、そのテストケースに合格させます。NUnitなどのユニットテストフレームワークは、失敗したテストケースがあると赤色のバーを表示し、すべてのテストケースが合格すると緑色で表示することから、よく次のようにも表現されます。
テストファースト： RED（失敗） → GREEN（成功）
次にリファクタリングは、製品コードの外部設計を変えずに（変わっていないことを保証しながら）、コードを読みやすく改良していくという内部設計を改善するプラクティスです。「動いているコードを触ってはいけない」という教えがありますが、それはコードを変更すると確認のための再テスト（回帰テスト）が大変だからです。テストファーストをしていれば自動実行できるテストケースのセットができ上がっていて、回帰テストは瞬時に終わりますから、古い教えに縛られる必要もないのです。
リファクタリング： 外部設計は変えちゃダメ！ vs 内部設計はどんどん改善！
リファクタリングで大事なことは、コードを少し変えるたびにテストを実行してGREENであることを確かめることです。製品コードの（外から見た）挙動が変わっていないことを保証できてこその、リファクタリングです。リファクタリングを始める前も、途中も、完了時も、常にGREENを維持し続けます。
リファクタリング： GREEN → GREEN → GREEN → …
そして、テストファーストのRED→GREENとリファクタリングを、テストケースごとに数分程度の短い間隔でリズミカルに回していきます。
TDD： RED → GREEN → リファクタリング → （…繰り返し…）
この記事では、主にテストファーストの手順を説明していきます。
例えば、MicrosoftとIBMとノースカロライナ州立大学が協力して行った研究があります。
- "Realizing quality improvement through test driven development: results and experiences of four industrial teams"（Empirical Software Engineering誌、2008年6月号）
その内容は、森崎修司氏（静岡大学助教）のブログ記事「テスト駆動開発（TDD）の事例 - IBMとMS 計4プロジェクトを紹介した論文 -」をご覧ください。
また、"ructured experiment of test-driven development"（Information and Software Technology Vol.46, 2004）においても、コーディング時間が16%増え、不具合数（20個の受け入れテストのうちで不合格だった数）が平均4ケース強から2ケース弱に半減したことが報告されています。これも、森崎氏がブログ記事で紹介しています。「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」
外部設計（external design）とは、設計対象を外から見たものです。大掴みに記述する概要設計（outline design）とは、まったく異なる概念です。同様に、内部設計（internal design）と詳細設計（detailed design）も別の概念です。
・設計の視点： 外部設計（external design） ⇒ 内部設計（internal design）
・記述の粒度： 概要設計（outline design） ⇒ 詳細設計（detailed design）
外部設計とは「どんなものを作ろうか」（what）であり、内部設計とは「どうやって作ろうか」（how）であるとも言えます。
外部設計を決めてから内部設計を行うというのは、当たり前すぎるくらいの手順（process）です。テストファーストが従来の手順と決定的に異なる点は、テストケースごとにテストを終えたメソッドの「完成品」を作り出すところです（コーディング前にユニットテストを設計することは、W字モデルなどでも行っています）。
テストファーストでは、メソッドの外部設計の一部分を1つのテストケースとして表現し、それに基いて内部設計（コーディング）を行い、ビルドしテストを実施するというループを順に繰り返します。テストファースト以前の発想では、外部設計をすべて決めてから、内部設計（コーディング）をすべて行ってメソッドを完成させ、それからテストを行いました（現実にはメソッドの外部設計を省略することも多いようです）。この変化を可能にしたのは、ビルドとテストの時間短縮と自動化によるコストダウンです。それにより、ビルドとテストをはるかに多く実施できるようになり、テストケースごとにループを回すことが実用になったのです。
なお、同じ要因が、アプリケーションの設計→アプリケーションのビルド→アプリケーションのテストという大きなループを数多く回すことをも可能にし、ユーザーストーリーごとに「完成品」を作り出すアジャイルソフトウェア開発プロセスを成立させています（このループを1回だけにしようとするのがウォーターフォール）。逆に言えば、ビルドやテストに時間が掛かったり、ビルドやテストが自動化されていなくてコストが高くつくようでは、TDDもアジャイル開発も成り立たないことになります。
TDD Boot Camp（TDDBC）
TDDBCのWikiページからの引用になりますが、TDDBCとは次のようなものです。
TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
各地のコミュニティの方々が中心となって、全国各地で行われています。
最初のTDDBCは、2009年12月に東京で開催されました（写真）※4。それから全国各地で催されるようになり、本稿執筆時点では20回におよびます（TDDBCのWikiによる）。TDDBCからは、座学では得ることのできない、体験と感動を持って帰ることができます。近くで開催されたおりには、ぜひ参加してみてください。
TDDBCの情報は、上記Wikiの他に次からも得ることができます。
- Twitter： ハッシュタグ #tddbc
- Facebook： コミュニティページ TDD Boot Camp
- Googleグループ： tddbc （運営スタッフ用ですが、どなたでも参加できます）
なお、TDDBCだけでなく、各地のコミュニティがTDDの勉強会を催していることもありますので探してみてください※5。
これには筆者も参加しました。その様子などをブログ記事「[イベント] TDD Boot Camp、いっぺんに 30組以上がペアプログラミングする壮観!」に書いてありますので、ご覧になってください。和田氏の講演資料や当日の録画などへのリンクもあります。
筆者は、わんくま同盟の勉強会（名古屋）の1セッションとして「TDD道場」を開催しています。
