BDD vs TDD vs ATDD：主な違い
このガイドポストは、ビヘイビア駆動開発（BDD）、テスト駆動開発（TDD）などのさまざまなテスト方法や手法を説明することを目的としています。 ）、受け入れテスト駆動開発（TDD）。また、これらの手法の主な違いを明確にするのにも役立ちます。この記事の終わりまでに、各方法がどのように機能するか、主な違い、および開発プロセスにおけるそれらの特定の役割を理解することが期待されます。
まず、テスト駆動開発から始めましょう。
テスト駆動開発（TDD）とは何ですか？
テスト駆動開発は、開発者の観点から実装されたテスト方法論またはプログラミング手法です。この手法では、QAエンジニアが、アプリケーションのすべての小さな機能のテストケースの設計と作成を開始します。この手法は、簡単な質問に答えようとします–コードは有効ですか？この手法の主な目的は、テストが失敗した場合にのみ新しいコードを変更または作成することです。したがって、テストスクリプトの重複が少なくなります。この手法は、アジャイル開発エコシステムで広く普及しています。 TDDアプローチでは、自動テストスクリプトは機能的なコードの前に記述されます。 TDD手法には、次の手順が含まれます。
- ドキュメントで指定された要件に基づいて、開発者は自動テストケースを作成します
- これらのテストが実行され、場合によっては実行されます。 、実際の機能を開発する前に開発されたため失敗します
- 開発チームは、テストに合格するためにコードをリファクタリングします
リファクタリング主な機能や動作を変更せずにコードを変更するプロセスを指します。 
テスト駆動開発の利点：
- やり直しに必要な時間を短縮するのに役立ちます
- バグやエラーを非常に迅速に調査するのに役立ちます
- より迅速なフィードバックを得るのに役立ちます
- よりクリーンで優れたデザインの開発を奨励します
- プログラマーの生産性を向上させます
- 特定のチームメンバーがいない場合でも、チームメンバーがコードの作業を開始できるようにします。これにより、知識の共有とコラボレーションが促進されます
- アプリケーションの大規模なアーキテクチャを簡単に変更できる自信がプログラマーに与えられます
- 柔軟性があり、保守が容易な広範なコードが作成されます
では、ビヘイビア駆動開発についてすべてを理解しましょう。
ビヘイビア駆動開発（BDD）とは何ですか？
ビジネス駆動開発（BDD）は、テスト駆動開発（TDD）方法論から派生したテストアプローチです。 BDDでは、テストは主にシステムの動作に基づいています。このアプローチは、その動作に基づいて機能を開発するためのさまざまな方法を定義します。ほとんどの場合、Given-When-Thenアプローチは、テストケースの作成に使用されます。理解を深めるために例を見てみましょう。
- ユーザーが有効なログイン資格情報を入力した場合
- ユーザーがログインボタンをクリックしたとき
- 次に表示成功した検証メッセージ
上記のように、動作は共有言語とも呼ばれる非常に単純な英語で示されています。これは、開発を担当するチームの全員が機能の動作を理解するのに役立ちます。
たとえば、に示すように、複数のデバイス間でテストする一連の手順に基づいて、簡単なクロスブラウザテストを実行してみることができます。ビデオ。
無料でRealDeviceCloudでブラウザテストを試す
ビヘイビア駆動の主な利点開発アプローチ：
- 非技術的な言語を使用することで、より多くのユーザーにリーチできます
- 顧客と開発者の観点からシステムがどのように動作するかに焦点を当てます
- BDDは費用効果の高い手法です
- 展開後の欠陥を検証するために必要な労力を削減します
以下の画像は、典型的なBDD操作を示しています。
画像ソース：チュートリアルポイント
BDDはSDLCでどのように役立ちますか？
開発ライフサイクルの後半でエラーをデバッグすることは、多くの場合、非常に費用がかかることが判明しますive。ほとんどの場合、要件を理解する際のあいまいさが、この背後にある根本的な原因です。すべての開発努力が、事前に決定された要件を満たすために調整されたままであることを確認する必要があります。 BDDを使用すると、開発者は次の方法で上記を実行できます。
- 単純な英語を使用した標準的なアプローチで要件を定義できるようにする
- 理解のための実際のシナリオを説明するいくつかの方法を提供する要件
- 技術チームと非技術チームが協力して要件を理解できるようにするプラットフォームを提供する
受け入れテスト駆動開発とは何ですか？
受け入れテスト駆動開発（ATDD）手法では、単一の受け入れテストがユーザーの観点から記述されます。これは主に、システムの機能的な動作を満たすことに重点を置いています。この手法は、質問に答えようとします–コードは期待どおりに機能していますか？
この手法により、開発者、ユーザー、QA間のコラボレーションが強化されます。受け入れ基準の定義について。 ATDDの主要なプラクティスの一部を次に示します。
- 実際のシナリオの分析と議論
- これらのシナリオの受け入れ基準の決定
- 受け入れテストケースの自動化
- これらの要件ケースの開発に焦点を当てる
ATDDの利点
- 要件は、あいまいさがある場合
- チーム間のメンバー間のコラボレーションを促進します
- 受け入れテストは、開発プロセス全体のガイドとして機能します
主な違い：TDD vs BDD vs ATDD
| パラメータ | TDD | BDD | ATDD |
| 定義 | TDDは、機能の実装に重点を置いた開発手法です | BDDは、システムの動作に焦点を当てた開発手法です | ATDDは、要件のキャプチャに重点を置いたBDDに似た手法です |
| 参加者 | 開発者 | 開発者、顧客、QA | 開発者、顧客、QA |
| 使用言語 | 機能開発に使用される言語と同様の言語で記述されています（例： Java、Pythonなど） | シンプルな英語、（Gherkin） | シンプルな英語、Gherkin |
| メインフォーカス | ユニットテスト | 要件の理解 | 承認テストの作成 |
| 使用するツール | JDave、Cucumber 、JBehave、Spec Flow、BeanSpec、Gherkin Concordian、FitNesse | Gherkin、Dave、Cucumber、JBehave、Spec Flow、BeanSpec、Concordian | TestNG、FitNesse、EasyB、Spectacular、Concordian、 Thucydides |
これらの方法がどのように機能するかを理解することは、開発者やソフトウェアに関わる他の個人を助けることができます開発は、どの戦略が目的を果たすのに最適かを判断します。プロジェクトの種類とそれが達成しようとしている結果に応じて、適切な方法（または方法の組み合わせ）を展開して、最も効率的な方法で特定の要件を満たすことができます。