テスト駆動開発（TDD）とは何ですか？例を使用したチュートリアル

No comments

テスト駆動開発

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

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

TDDの単純な概念は、失敗したテストを記述して修正してから書き込むことです。新しいコード（開発前）。これにより、テストに合格するために一度に少量のコードを作成するため、コードの重複を回避できます。 （テストは、それらを満たすためにテストする必要がある要件条件に他なりません。）

テスト駆動開発は、自動化された開発と実行のプロセスです。アプリケーションの実際の開発前にテストします。したがって、TDDはテストファースト開発とも呼ばれます。

このチュートリアルでは、詳細を学習します-

  • TDDテストの実行方法
  • TDDと従来のテスト
  • 受け入れTDDおよび開発者TDDとは
  • アジャイルモデル駆動開発（AMDD）によるTDDのスケーリング
  • テスト駆動開発（TDD）とアジャイルモデル駆動開発（AMDD）
  • TDDの例
  • TDDの利点

TDDテストの実行方法

次の手順では、TDDテストの実行方法を定義します。

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

TDDサイクルの定義

  1. テストの作成
  2. 実行する
  3. コードの変更正しくするために、つまりリファクタリングします。
  4. プロセスを繰り返します。

TDDに関するいくつかの説明：

  • TDDは「テスト」に関するものでもありません。また、「設計」についても同様です。
  • TDDは、「いくつかのテストを作成してから、テストに合格するシステムを構築する」という意味ではありません。
  • TDDは「多くのテストを行う」という意味ではありません。 “

TDDと従来のテスト

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

  • 従来のテストでは、テストが成功すると1つ以上の欠陥が見つかります。 TDDと同じです。テストが失敗した場合、問題を解決する必要があることがわかっているため、進歩を遂げています。
  • TDDは、システムが実際に定義された要件を満たしていることを確認します。システムに対する信頼を築くのに役立ちます。
  • TDDでは、テストが適切に機能するかどうかを検証する本番コードに重点が置かれています。従来のテストでは、テストケースの設計により重点が置かれています。要件を満たすために、テストでアプリケーションの適切/不適切な実行が示されるかどうか。
  • TDDでは、100％のカバレッジテストを達成します。従来のテストとは異なり、コードのすべての行がテストされます。
  • 従来のテストとTDDの両方を組み合わせると、システムの完全性ではなく、システムをテストすることが重要になります。
  • Inアジャイルモデリング（AM）の場合、「目的を持ってテストする」必要があります。何かをテストする理由と、テストする必要のあるレベルを知っておく必要があります。

受け入れTDDと開発者TDDとは

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

  1. 受け入れTDD（ATDD）：ATDDを使用して、単一の受け入れテストを記述します。このテストは、仕様の要件を満たすか、システムの動作を満たします。その後、その受け入れテストを満たすのに十分な本番/機能コードを記述します。受け入れテストは、システムの全体的な動作に焦点を当てています。 ATDDは、ビヘイビア駆動開発（BDD）とも呼ばれていました。
  2. 開発者TDD：開発者TDDを使用して、単一の開発者テスト、つまり単体テストを作成し、そのテストを満たすのに十分な本番コードを作成します。ユニットテストは、システムのすべての小さな機能に焦点を当てています。開発者TDDは単にTDDと呼ばれます。

    ATDDおよびTDDの主な目標は、ソリューションの詳細で実行可能な要件をジャストインタイム（JIT）ベースで指定することです。 JITとは、システムで必要とされる要件のみを考慮に入れることを意味します。したがって、効率を上げます。

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

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

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

AMDDのライフサイクル。

モデル駆動型開発（MDD）では、広範なモデルが作成される前にソースコードが書かれています。どちらがアジャイルアプローチを持っていますか？

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

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

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

  1. 反復0：構想

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

  1. 想定される初期要件。

    システムの高レベルの要件と範囲を特定するには、数日かかる場合があります。主な焦点は、使用モデル、初期ドメインモデル、およびユーザーインターフェイスモデル（UI）を調査することです。

  2. 初期のアーキテクチャの構想。

    システムのアーキテクチャを特定するのにも数日かかります。プロジェクトの技術的な方向性を設定できます。主な焦点は、テクノロジダイアグラム、ユーザーインターフェイス（UI）フロー、ドメインモデル、および変更ケースを調査することです。

  1. 反復モデリング：

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

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

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

  • ここでのモデリングセッションには、紙またはホワイトボードで問題について話し合う2/3のメンバーのチームが含まれます。
  • 1人のチームメンバーが別のチームメンバーに質問しますそれらでモデル化する。このモデリングセッションには、約5〜10分かかります。チームメンバーが集まってホワイトボード/ペーパーを共有する場所。
  • 問題の主な原因が見つからなくなるまで問題を調査します。1人のチームメンバーが必要な問題を特定した場合、ちょうど間に合います。解決するために、彼/彼女は他のチームメンバーの迅速な助けを借ります。
  • 他のグループメンバーが問題を調査し、その後全員が以前と同じように続行します。これは、スタンドアップモデリングまたは顧客QAセッションとも呼ばれます。 。
  1. テスト駆動開発（TDD）。
  • アプリケーションコードと詳細な仕様の確認テストを促進します。
  • 受け入れテスト（詳細な要件）と開発者テスト（ユニットテスト）の両方がTDDの入力です。
  • TDDにより、コードがよりシンプルで明確になり、開発者が維持できるドキュメントが少なくなります。
  1. レビュー。
  • これはオプションです。コード検査とモデルレビューが含まれます。
  • これは次のようになります。反復ごとまたはプロジェクト全体に対して実行されます。
  • これは、プロジェクトにフィードバックを提供するための優れたオプションです。

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

TDDの例

この例では、クラスパスワードを定義します。このクラスでは、以下の条件を満たすように努めます。

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

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

まず、コードを記述します上記のすべての要件を満たしています。

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

クラスTestPassword（）;の上で実行します。

以下に示すように、出力はPASSEDです。

出力：

シナリオ2：ここでメソッドTestPasswordLength（）を参照してください。クラスPasswordValidatorのインスタンスを作成する必要はありません。インスタンスとは、そのクラスのメンバー（変数/メソッド）を参照するクラスのオブジェクトを作成することを意味します。

クラスPasswordValidatorpv = new PasswordValidator（）をコードから削除します。 PasswordValidatorによってisValid（）メソッドを直接呼び出すことができます。 IsValid（ “Abc123″）。（下の画像を参照）

したがって、以下のようにリファクタリング（コードを変更）します：

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

public static boolean isValid（String password）として、ブール値の前に「static」という単語を追加して、このメソッドを変更する必要があります。クラスPasswordValidator（）をリファクタリングして、上記のエラーを削除し、テストに合格します。

出力：

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

TDDの利点

  • 初期のバグ通知。

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

  • より適切に設計され、よりクリーンで、より拡張可能なコード。
    • コードがどのように使用され、他のモジュールとどのように相互作用するかを理解するのに役立ちます。
    • 設計の決定が改善され、コードが保守しやすくなります。
    • TDD複数の責任を持つモノリシックな手順ではなく、単一の責任を持つ小さなコードを書くことができます。これにより、コードが理解しやすくなります。
    • TDDは、ユーザーの要件に基づいてテストに合格するために、本番コードのみを記述することも強制します。
  • リファクタリングへの信頼
    • コードをリファクタリングすると、コードが破損する可能性があります。したがって、一連の自動テストがあれば、リリース前にそれらの中断を修正できます。自動テストの使用時に破損が見つかった場合は、適切な警告が表示されます。
    • TDDを使用すると、最小限のリスクで更新できるバグが少なく、より高速で拡張性の高いコードが得られます。
  • チームワークに適しています

    チームメンバーがいない場合、他のチームメンバーは簡単にコードを取得して作業できます。また、知識の共有を支援し、それによってチーム全体をより効果的にします。

  • 開発者に適しています

    開発者はTDDテストケースの作成により多くの時間を費やす必要がありますが、デバッグと新機能の開発にかかる時間ははるかに短くなります。よりクリーンで複雑でないコードを記述します。

概要：

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

この記事はKanchanKulkarniによって寄稿されました

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です