テスト駆動開発（TDD）とは

開発者は各テストで合格するために必要な最小限のコードを書き、その後テストとコードの両方を改善してから、新しいテストや新しい機能へと進みます。

テスト駆動開発は、本質的に開発者に開発のペースを落とし、短いフィードバックサイクルの中でコードを検証・改善することを促します。必須ではありませんが、DevOpsチームは、初心者から経験豊富なプロフェッショナルまで、幅広いプログラミング言語でTDDを活用することを推奨しています。例えば、JavaやPythonなどのプログラミング言語、アプリケーション・プログラミング・インターフェース（API）、およびプログラム・アプリケーションがあります。

このスタイルでプログラミングを行うことで、コーディング、テスト（自動化されたユニットレベルのテスト）、コード設計の関係が強化されます。テスト駆動開発は当初の開発時間を増加させる可能性がありますが、コードの機能性や柔軟性を向上させ、結果的に全体の時間を節約できることが実証されています。

TDDを活用する開発者は、エラーを即座に特定して対処することで、小さな問題が大きな課題に発展するのを防ぐことができます。テスト駆動開発では、開発者にコードを検証しつつ改善することを求めるため、最終的な品質チェックや修正が効率化されます。

代替的なテスト手法としては、すべての自動テストを書く前に本番コードを書く方法や、本番コードを書く前にテスト・スイート全体を書く方法があります。これらの方法は必ずしも非効率というわけではありませんが、特に大規模で複雑なプロジェクトにおいては、必要なデバッグ時間が増えることが示されています。

テスト駆動開発は新しい本番コードの作成に広く用いられていますが、従来の手法や他の技術で開発されたレガシー。コードのデバッグを改善するためにもよく活用されています。

テスト駆動開発は、開発よりも先にテストを行うことで、従来の開発プロセスを逆転させます。反復的なアプローチとして、テスト駆動開発はテスト可能なワークフローを促進し、ユニット・レベルで高品質なコードを実現することで、コードの品質と可読性を向上させます。開発者がユニット・テストを行う際は、個々のアルゴリズムのような小さなロジックの一部に焦点を当てます。テストに合格させることを目的にコードを書くことで、よりクリーンで耐久性の高いコードになるだけでなく、ドキュメントの改善にもつながります。

テスト駆動開発には2つの主要なレベルがあります。

受け入れTDD（Behavior-Driven Development〔BDD〕とも呼ばれる）では、プログラマーは1つの受け入れテストを書き、そのテストに合格するために必要な新しいコードを実行します。受け入れテストは、カスタマー・テストまたはカスタマー受け入れテストと呼ばれることもあります。

それらは一般的に、製品の利害関係者によって示される最小限の機能に必要なテストケースとして理解されます。ATDDは、詳細で実行可能な要件を特定することを目指します。受け入れテストは、FitnesseやRSpecなどのさまざまなテスト・ツールを使用して実施できます。

単にTDDと呼ばれることもある開発者TDDでは、コーダーはATDDテストに対する自分の解決策を評価するために個々のテストを書きます。開発者TDDでは、JUnitやVBUnitなどのテスト自動化ツールが使用されます。

テスト駆動開発の手法を採用する場合、コーダーはまずソフトウェアの各要素や機能を確認するテストを書き、その個々のテストに合格するために必要なコードを記述します。完了するとソフトウェアは再度テストされ、テストに合格した場合は、必要な要素だけを残すようにコードが改善されます（このプロセスはリファクタリングと呼ばれます）。その後、開発者はこのプロセスをソフトウェアの各後続機能に対して繰り返します。

テスト駆動開発のプロセスは、5つのステップに分けられます。

1. 特定のソフトウェア機能のコードを書く前に、開発者はまずその機能用の個別のユニット・テストを作成します。
2. 次に開発者はそのテストを実行しますが、コードの機能がまだ書かれていないため失敗するはずです。このステップは、テスト自体が正しく機能し、誤検知を返さないことを確認するうえで重要です。コードが合格してしまった場合は、そのテストを書き直す必要があります。
3. プログラムがテストに失敗した場合、開発者はそのテストに合格するために必要な最小限の追加コードだけを書きます。
4. コードがテストに合格すると、テストとコードの両方が単純化のためにリファクタリングされ、不要なコードが取り除かれます。
5. 十分にリファクタリングされたソフトウェアがリファクタリング後のテストに合格すると、開発者は次に必要なソフトウェア機能へと進み、その後、テスト担当者が新しい機能ごとにテストを作成して実行します。

簡単に言えば、テスト駆動開発のプロセスは「レッド・グリーン・リファクター」サイクルと呼ばれる反復可能なループに従います。サイクルのステップは次のとおりです。

• レッド：想定するソフトウェアの動作に対して失敗するテストを書く。

• グリーン：テストに合格するのに十分な量を書く。

• リファクター：テストに合格しつつ、可能な限り単純さの基準を満たすようにコードを改善する。

テスト駆動開発の正確な起源は不明ですが、テストを先に書き、本番コードを後から書くという考え方は、1990年代半ばまでは一般的な手法ではありませんでした。それ以前のテストフレームワークでは、開発者が自分のコードベースを直接テストすることはできませんでした。しかし、ソフトウェア・エンジニアリングが進化するにつれて、特に急速に変化する利害関係者の要件に対応するために、DevOpsチームはより迅速で柔軟な手法を求めるようになりました。

テスト駆動開発は、さまざまな新しいテストフレームワークとともに進化し、またモジュール型のコンポーネントとして他のさまざまなフレームワークにも採用されています。特筆すべきは、TDDがExtreme Programming（XP）の概念に含まれている点です。XPは、ソフトウェアの品質と開発者の生活の質の双方を向上させるために開発されたアジャイル・ソフトウェア開発フレームワークです。

ソフトウェア・エンジニアで、アジャイル・コミュニティーの主要人物で、XPの創始者でもあるKent Beck氏は、テスト駆動開発を『再発見』した人物として知られています。Beck氏は次のように語っています。 

「TDDの最初の説明は、プログラミングに関する古い書籍にありました。入力テープを取り、期待する出力テープを手作業で入力し、実際の出力テープが期待した出力と一致するまでプログラムを書く、と記されていました。私がSmalltalkで最初のxUnitフレームワークを書いた後、この記述を思い出して試してみました。それが私にとってのTDDの起源です。TDDを年配のプログラマーに説明すると、よく「当たり前だ。ほかにどうやってプログラミングするんだ？」と言われます。だからこそ、私は自分の役割をTDDを『再発見』したことだと表現しています」。

テスト駆動開発の進化における注目すべき日付には、次のものがあります。

• 1976年：Glenford Myers氏が著書『Software Reliability』を出版し、その中で「開発者は自分のコードを決してテストすべきではない」と主張しました。Myers氏がこの概念の発案者ではなかったかもしれませんが、その著作は、この後長年にわたり広まることになる一般的な考え方に信頼性を与えました。

• 1990年：この年代の初めには、「ブラック・ボックス」手法がソフトウェア・テストの主流でした。この種のテスト・フレームワークでは、テスト担当者はソフトウェアを「ブラック・ボックス」として扱い、内部を把握できず理解できないものと見なします。ブラック・ボックス・テストでは、ソフトウェアの内部構造について知識を持たない人をテスト担当者として起用することが重要な特徴です。

• 1994年：Kent Beck氏がSmalltalk用のテスト・フレームワーク「SUnit」を開発し、コードベースの最適化に向けたテスト・ファーストのアプローチの基盤を築きました。

• 1999〜2002年：アジャイル開発の動きが勢いを増す中、Kent Beck氏がExtreme Programmingの概念を提唱し、テスト駆動開発を体系化するとともに、モック・オブジェクトという重要な概念を導入しました。TDDでは、テスト中に実際の依存関係（例えばデータベースや外部サービスなど）の動作をシミュレートするためにモック・オブジェクトを使用します。この方法により、開発者はテスト・コードを保守可能なモック・オブジェクトに集中させ、その動作を正確に検証できるようになります。モック・オブジェクトを使用した失敗テストは、失敗の原因として考えられる依存関係の誤設定を排除することができます。

• 2003年：Kent Beck氏が著書『Test Driven Development: By Example』を出版し、開発コミュニティー全体にTDDを広めるとともに、開発者主導のテストをさらに正当化しました。

Extreme Programmingの要素として、テスト駆動開発はより良いコードを生み出すだけでなく、より優れた開発者を育成するうえでも有益であることがわかっています。TDDは、コーダーが自分のプロジェクトに対する理解を深め、プログラム設計を推進する助けにもなります。各機能を実装する前にテストケースを中心に据えることで、開発者はその機能がクライアントやユーザーにどのように利用されるかをイメージしなければなりません。このアプローチは、実装に先立って製品インターフェースを位置付け、開発者がよりユーザー中心のアプリケーションを作成するのに役立ちます。

テスト駆動開発の追加的なメリットには、次のようなものがあります。

• 包括的なテストカバレッジ：TDDは、すべてのコードが少なくとも1つのテストでカバーされることを保証するため、仕様やドキュメンテーション・ツールと呼ばれることもあります。

• ドキュメンテーションの改善：TDDではテストが仕様や設計の根拠として機能するため、明確で信頼性の高いドキュメントを提供できます。この仕組みにより、開発者、プロジェクトマネージャー、その他の利害関係者は、コードの機能や要件を検証し、プロジェクトのライフサイクル全体を通じて秩序を確立できます。

• 信頼性の向上：TDDを活用する開発者やDevOpsチームは、自分たちのコードだけでなくテストそのものにもより大きな信頼を持つことができます。

• 継続的統合の促進：TDDは、稼働中のコードに新機能やパッチを継続的に追加していく継続的統合の実践に適しています。

• デバッグの削減：TDDは開発プロセスの初期段階でテストを集中的に行うため、開発の後半で大規模なデバッグを行う必要が少なくなります。

• 要件の明確化：TDDは、作業を始める前に各プログラム要件を明確に理解するのに役立ちます。

• 生産性の向上：TDDは、大規模なプロジェクトをより小さく達成可能なステップに分割するプロセスを助けるため、開発者の生産性向上につながることがよくあります。

• シンプルな設計の強化：グリーン・レッド・リファクターというTDDサイクルの重要な第3ステップでは、開発者にコードのリファクタリングと単純化が求められます。この実践により、全体的なシンプルさとデザインの品質が向上します。

• メンタル・モデルの強化：TDDは、すべての固有の機能や要件を検証・統合することで、コーダーが対象コードに対する強固なメンタル・モデルを構築するのに役立ちます。このメンタル・モデルにより、開発者は作業中のコード全体の機能や要件を可視化できます。

• システム安定性の向上：テスト駆動開発を採用することで、設計の単純さに関する高い基準に沿った堅牢で十分にテストされたコードが生成され、アプリケーション全体の安定性が向上することが実証されています。

テスト駆動開発（TDD）には多くのメリットがありますが、課題がないわけではありません。これらの課題の深刻さはプロジェクトによって異なったり、さまざまな手法で軽減できたりしますが、TDDの欠点としては次のようなものがあります。

• コード量の増加：TDDでは、必要な各機能のコードだけでなく、その機能ごとのテストも記述する必要があります。テスト・コードをプロダクト・コードとあわせて追加することで、全体のコードベースが大きくなります。

• 誤った安心感：各機能がテストに合格するように書かれるため、コード作成担当者やプロジェクト・マネージャーがコード全体の機能性について誤った安心感を抱いてしまう可能性があります。各統合機能がテストされているとしても、TDDは最終的な品質管理やAPIテストの必要性を置き換えるものではありません。

• 諸経費の増加：TDDでは、プロダクト・コードに加えて大量のテスト・スイートも維持する必要があります。テスト・コードベースの維持には一定量の参考情報が必要で、諸経費が増加する可能性があります。

• 効率の低下：TDDは生産性を向上させることが示されていますが、新しい機能の作成と実装に追加のステップが加わるため、プロジェクト開発を遅延させる可能性があります。

• セットアップ時間の増加：TDDでは、開発者がコード用の適切なテスト環境を構築し、維持する必要があります。

• 全体設計の軽視：TDDはコードの単純化や設計の改善を促しますが、個々のコンポーネントに過度に集中すると、コード全体の調和が損なわれる可能性があります。TDDを利用するコード作成担当者は、自分の担当する個々の機能更新が、全体のソフトウェア・アプリケーションにコンパイルされたときにどのように統合されるのかを理解しておく必要があります。