テスト駆動開発 (TDD) とは何ですか? 例

替え： トーマス・ハミルトン トーマス・ハミルトン
Hours 更新中

テスト駆動開発 (TDD) とは何ですか?

テスト駆動開発 (TDD) は、コードが何を行うかを指定および検証するためにテスト ケースを開発するソフトウェア開発アプローチです。 簡単に言えば、各機能のテスト ケースが最初に作成およびテストされ、テストが失敗した場合は、テストに合格するために新しいコードが作成され、コードがシンプルでバグがなくなります。

テスト駆動開発は、アプリケーションのあらゆる小さな機能に対するテストを設計および開発することから始まります。 TDD フレームワークは、自動テストが失敗した場合にのみ新しいコードを書くように開発者に指示します。 これにより、コードの重複が回避されます。 TDD の完全な形式はテスト駆動開発です。

テスト駆動開発

TDD の単純な概念は、新しいコードを作成する前 (開発前) に、失敗したテストを作成して修正することです。 これは、テストに合格するために一度に少量のコードを記述するため、コードの重複を避けるのに役立ちます。 (テストは要件を満たすためにテストする必要がある要件にほかなりません)。

テスト駆動開発は、アプリケーションを実際に開発する前に、自動テストを開発および実行するプロセスです。 したがって、TDD は次のように呼ばれることもあります。 最初の開発をテストします。

TDDテストの実行方法

以下の手順はTDDテストの実行方法を定義します。

  1. テストを追加します。
  2. すべてのテストを実行し、新しいテストが失敗するかどうかを確認します。
  3. いくつかのコードを書いてください。
  4. テストを実行し、コードをリファクタリングします。
  5. 繰り返す。
TDDテストを実行する
テスト駆動開発の XNUMX つのステップ

TDDサイクルの定義

  1. テストを書く
  2. 実行させてください。
  3. コードを変更して正しくします。つまり、リファクタリングします。
  4. プロセスを繰り返します。

TDD についてのいくつかの説明:

  • TDD アプローチは「テスト」でも「設計」でもありません。
  • TDD は、「テストをいくつか書いてから、テストに合格するシステムを構築する」という意味ではありません。
  • TDD は「たくさんのテストを行う」という意味ではありません。

TDD と従来のテスト

以下は、テスト駆動開発と従来のテストの主な違いです。

TDD アプローチは主に仕様策定の手法です。これにより、ソース コードが確認レベルで徹底的にテストされることが保証されます。

  • 従来のテストでは、テストが成功すると XNUMX つ以上の欠陥が見つかります。 TDDと同じです。 テストが失敗したときは、問題を解決する必要があることがわかっているため、進歩したことになります。
  • TDD は、システムが実際に定義された要件を満たしていることを保証します。 これは、システムに対する自信を高めるのに役立ちます。
  • TDD では、テストが適切に機能するかどうかを検証する実稼働コードに重点が置かれます。 従来のテストでは、テスト ケースの設計に重点が置かれています。 要件を満たすためにアプリケーションが適切に実行されているか、不適切に実行されているかをテストで示すかどうか。
  • TDD では、100% カバレッジ テストを達成します。 従来のテストとは異なり、コードのすべての行がテストされます。
  • 従来のテストと TDD の両方を組み合わせると、システムの完璧さよりもシステムをテストすることが重要になります。
  • In アジャイルモデリング (AM)、「目的を持ってテストする」必要があります。 なぜ何かをテストするのか、どのレベルでテストする必要があるのか​​を理解する必要があります。

関連記事

アクセプタンスTDDと開発者TDDとは何ですか

TDD には XNUMX つのレベルがあります

  1. 受け入れ TDD (ATDD): ATDD では、単一の受け入れテストを作成します。 このテストは、仕様の要件を満たすか、システムの動作を満たします。 その後、受け入れテストを満たすのに十分な量の運用/機能コードを作成します。 受け入れテストは、システムの全体的な動作に焦点を当てます。 ATDD は別名 行動駆動型開発 (BDD).
  2. 開発者TDD: Developer TDD を使用すると、単一の開発者テスト (つまり単体テスト) を作成し、その後、そのテストを実行するのに十分な実稼働コードを作成します。 単体テストは、システムのあらゆる小さな機能に焦点を当てます。 開発者 TDD は単に次のように呼ばれます。 TDD。ATDD と TDD の主な目的は、ソリューションの実行可能な詳細な要件をジャスト イン タイム (JIT) ベースで指定することです。 JIT とは、システムで必要な要件のみを考慮することを意味します。 したがって、効率が向上します。

アクセプタンス TDD と開発者 TDD

アジャイルモデル駆動開発 (AMDD) による TDD のスケーリング

TDD は詳細な仕様と検証を非常に得意としています。 全体的なデザイン、システムの使用法、UI など、より大きな問題について考えることができません。 AMDD は、TDD では解決できないアジャイル スケーリングの問題に対処します。

したがって、AMDD はより大きな問題に使用されます。

AMDDのライフサイクル

AMDD のライフサイクル

モデル駆動開発 (MDD) では、ソース コードを記述する前に広範なモデルが作成されます。 では、アジャイルなアプローチを採用しているのはどれでしょうか?

上の図では、各ボックスは開発アクティビティを表しています。

構想は、プロジェクトの最初の週に実行されるテストを予測/想像する TDD プロセスの 1 つです。構想の主な目的は、システムの範囲とシステムのアーキテクチャを特定することです。構想を成功させるには、高レベルの要件とアーキテクチャのモデリングが行われます。

これは、ソフトウェア/システムの詳細な仕様を作成するのではなく、プロジェクトの全体的な戦略を定義するソフトウェア/システムの要件を検討するプロセスです。

イテレーション 0: 想像する

XNUMX つの主なサブアクティブ化があります。

  1. 初期要件の想定。システムの高レベルの要件と範囲を特定するには数日かかる場合があります。 主な焦点は、使用モデル、初期ドメイン モデル、およびユーザー インターフェイス モデル (UI) を調査することです。
  2. 初期 Archi構造的な想像力。 システムのアーキテクチャを特定するのにも数日かかります。これにより、プロジェクトの技術的な方向性を設定できます。主な焦点は、テクノロジ ダイアグラム、ユーザー インターフェイス (UI) フロー、ドメイン モデル、および変更ケースの調査です。

反復モデリング

ここでチームは、各反復で実行される作業を計画する必要があります。

  • アジャイル プロセスは各反復で使用されます。つまり、各反復中に、新しい作業項目が優先的に追加されます。
  • 最初に優先順位の高い作業が考慮されます。 追加された作業項目はいつでも優先順位を変更したり、項目スタックから削除したりできます。
  • チームは、各要件をどのように実装するかについて話し合います。 この目的のためにモデリングが使用されます。
  • モデリング分析と設計は、その反復で実装される要件ごとに行われます。

モデルストーミング

これは、ジャスト イン タイム モデリングとも呼ばれます。

  • ここでのモデリング セッションには、2/3 のメンバーからなるチームが参加し、紙またはホワイトボード上で問題について話し合います。
  • チーム メンバーの 5 人が、別のチーム メンバーにモデルを依頼します。 このモデリング セッションには約 10 ～ XNUMX 分かかります。 チームメンバーが集まってホワイトボードや紙を共有する場所。
  • 彼らは、問題の主な原因が見つかるまで問題を調査します。 ちょうどいいタイミングで、チーム メンバーの XNUMX 人が解決したい問題を特定した場合、その人は他のチーム メンバーの迅速な支援を受けるでしょう。
  • その後、他のグループのメンバーが問題を検討し、全員が以前と同じように作業を続けます。 スタンドアップ モデリングまたは顧客 QA セッションとも呼ばれます。

テスト駆動開発 (TDD)

  • アプリケーション コードと詳細な仕様の確認テストを促進します。
  • 受け入れテスト (詳細な要件) と開発者テスト (単体テスト) は両方とも TDD の入力です。
  • TDD により、コードがより単純かつ明確になります。 これにより、開発者が維持するドキュメントが少なくなります。

レビュー

  • これはオプションです。 これには、コード検査とモデルレビューが含まれます。
  • これは、反復ごとに、またはプロジェクト全体に対して実行できます。
  • これは、プロジェクトにフィードバックを提供するのに良いオプションです。

テスト駆動開発 (TDD) とアジャイルモデル駆動開発 (AMDD)

TDD AMDD
TDD はプログラミングのフィードバック ループを短縮します AMDD はモデリングのフィードバック ループを短縮します。
TDDは詳細仕様です AMDD はより大きな問題に対して機能します
TDDは高品質なコードの開発を促進する AMDD は、利害関係者や開発者との質の高いコミュニケーションを促進します。
TDD がプログラマーに語る AMDD との対話 ビジネスアナリスト、関係者、データ専門家。
TDD 非ビジュアル指向 AMDD の視覚指向
TDDの範囲はソフトウェア作品に限定される AMDDはステークホルダーを含む幅広い範囲を対象としています。 共通理解に向けて取り組むことが必要です
どちらも進化的発達をサポートします ---------------

TDD フレームワーク

これは、最高のテスト駆動開発 (TDD) フレームワークのリストです。

  1. ジュニット
  2. TestNG
  3. csUnit と NUnit
  4. Rスペック

ここで、例を挙げてテスト駆動開発を学びましょう。

TDDの例

このテスト駆動開発の例では、クラス パスワードを定義します。このクラスでは、次の条件を満たすようにします。

パスワードを受け入れるための条件:

  • パスワードは5〜10文字である必要があります。

この TDD の例では、まず、上記の要件をすべて満たすコードを作成します。

TDDの例

シナリオ1: テストを実行するには、クラス PasswordValidator (); を作成します。

TDDの例

クラス TestPassword (); の上で実行します。

以下に示すように、出力は PASSED になります。

出力:

TDDの例

シナリオ2: ここで、メソッド TestPasswordLength () では、クラス PasswordValidator のインスタンスを作成する必要がないことがわかります。 インスタンスとは、 オブジェクト クラスのメンバー (変数/メソッド) を参照します。

TDDの例

コードからクラス PasswordValidator pv = new PasswordValidator () を削除します。 を呼び出すことができます。 有効です() 直接的な方法 パスワード検証器。 IsValid (「Abc123」)。 (下の画像を参照)

そこで、以下のようにリファクタリング（コードを変更）します。

TDDの例

シナリオ3: リファクタリング後、出力に失敗ステータスが表示されます（下の画像を参照）。これはインスタンスを削除したためです。そのため、非静的メソッドへの参照はありません。 有効です()。

TDDの例

したがって、このメソッドを変更するには、ブール値の前に「静的」という単語を public static boolean isValid (文字列パスワード) として追加する必要があります。 クラス PasswordValidator () をリファクタリングして上記のエラーを削除し、テストに合格します。

TDDの例

出力：

PassValidator () クラスに変更を加えた後、テストを実行すると、以下に示すように出力が PASSED になります。

TDDの例

TDDの利点

ソフトウェア エンジニアリングにおけるテスト駆動開発の主な利点は次のとおりです。

早期のバグ通知。

  • 開発者はコードをテストしますが、データベースの世界では、これは多くの場合、手動テストまたは XNUMX 回限りのスクリプトで構成されます。 TDD を使用すると、時間をかけて、あなたや他の開発者が自由に再実行できる一連の自動テストを構築できます。

デザインが改善され、よりクリーンで拡張性の高いコード。

  • コードがどのように使用され、他のモジュールとどのように相互作用するかを理解するのに役立ちます。
  • その結果、設計上の意思決定が改善され、コードがより保守しやすくなります。
  • TDD を使用すると、複数の責任を持つモノリシックなプロシージャではなく、単一の責任を持つより小さなコードを作成できます。 これにより、コードが理解しやすくなります。
  • また、TDD は、ユーザーの要件に基づいたテストに合格する実稼働コードのみを記述することを強制します。

リファクタリングに対する自信

  • コードをリファクタリングすると、コードが破損する可能性があります。 したがって、一連の自動テストを使用することで、リリース前に問題を修正できます。 自動テストの使用時に破損が見つかった場合は、適切な警告が表示されます。
  • TDD を使用すると、最小限のリスクで更新できるバグが少なく、より高速で拡張性の高いコードが得られます。

チームワークに最適

  • チーム メンバーがいない場合は、他のチーム メンバーが簡単にコードを取得して作業できます。 また、知識の共有にも役立つため、チーム全体の効率が向上します。

開発者にとって良いこと

  • 開発者は TDD テスト ケースの作成に多くの時間を費やす必要がありますが、デバッグや新機能の開発にかかる時間は大幅に短縮されます。 より簡潔で複雑さの少ないコードを作成できるようになります。

製品概要

  • TDDはテスト駆動開発の略です。
  • TDD の意味: 以前に設計されたテストに合格するためにコードを変更するプロセスです。
  • テストケースの設計よりも実稼働コードに重点を置いています。
  • テスト駆動開発は、以前に設計されたテストに合格するためにコードを変更するプロセスです。
  • In ソフトウエアエンジニアリング、として知られることもあります。 「テストファースト開発」
  • TDD テストには、コードのリファクタリング、つまり、コードの動作に影響を与えることなく、既存のコードにある程度のコードを変更/追加することが含まれます。
  • TDD プログラミングを使用すると、コードがより明確になり、理解しやすくなります。