TDD に慣れているなら、ATDD はより高度なテストと関係者が多い TDD といったところです。 TDD についてもっと知りたい場合は、次の投稿を確認してください:
Acceptance test-driven development (ATDD) は、ビジネス顧客、開発者、およびテスター間のコミュニケーションに基づく開発方法論です。 ATDDは、例による仕様、振る舞い駆動開発（BDD）、例駆動開発（EDD）、サポート駆動開発（ストーリーテスト駆動開発（SDD）とも呼ばれる）と同じ実践を多く包含している。 これらのプロセスはすべて、開発者とテスターが実装前に顧客のニーズを理解し、顧客が自分のドメイン言語で会話できるようにするためのものです。
Agile チーム内で広く実施されている ATDD は、ビジネス アナリスト、開発者、テスター、およびユーザーが一緒になって、開発プロセスの早い段階（コーディング開始前）でそれぞれのストーリー（または機能）の受け入れ条件を定義するプラクティスです。 このアプローチにより、開発者がコーディングを始める前に、すべての利害関係者が同じレベルの期待結果を持ち、それを維持することができます。
「開発者は仕様を気にしない、テスターは自動化をやりたがらない」というステレオタイプを聞いたことがあると思いますが、ATDD では、開発者が仕様の初期段階にもっと関与し、テスターが受け入れテストを自動化することによって、多くの時間と費用の無駄を省くことができます。 もしそうでなければ、次の例があなたの好奇心を満たすに違いありません。
例
製品オーナーまたはクライアントが、私たちのモバイル アプリケーションに次の機能を要求したと仮定しましょう。 「ユーザーとして、アプリケーションを匿名で使用できるようにログイン画面を回避したい」 この要求をすべてのチーム (ビジネス アナリスト、開発者、テスター…) でレビューし、ストーリーまたは機能に詳細を追加した後、これに似たいくつかの「受け入れ」または「機能」テストを作成します (これは単なる例であり、多くの受け入れテストがこの機能に対して不足していることに留意してください)。
- 許容基準 1: アプリケーションはログインするためにオプションでログイン/パスワードを受け入れる
- 許容基準 2: ボタン バイパスにより、ユーザーはログインせずにアプリケーション内でブラウズすることができる。
- Acceptance Criteria 3: ボタン・バイパスを選択した場合、アプリケーションはユーザー固有の情報を保存または表示しません。
メリット
1- 顧客と販売者の整合性：入力情報として上記の受け入れ基準を持つことにより、我々（すべてのチームメンバー）は、アプリケーションがログイン/パスワード機能を維持し、ユーザーがログイン画面をバイパスするためのボタンを追加するだけであることを確信することができるようになりました。 上記のテストは、開発者がコーディングを開始する前でも簡単に自動化することができます。 テストが実装されると、開発者は、終了したことを発表する前に、必要なタスクを検証できます。 重要なことは、すべての受け入れテストを自動化する必要はないということです。 テストの自動化は、技術的な課題、納期、コストなど、複数の側面に依存します。 重要なのは、すべての受け入れテストを自動化する必要はない、ということです。 テストの自動化は、技術的な課題、納期、コストなどの複数の側面に依存します。
このセクションでは、ATDD で最も使用されている自動化ツールの概要を説明します。 完全に統合されたスタンドアロンの wiki および受け入れテスト フレームワーク
Robot framework: 受け入れテストおよび受け入れテスト駆動開発 (ATDD) のための汎用テスト自動化フレームワーク
Calabash: モバイルアプリの受け入れテスト自動化 – このフレームワークは、最新のOSバージョン（Android O以上）をサポートしていない場合がありますのでご注意ください )