単体テストと TDD の利点を説明する短い論文を書いています。最後に「TDD を超えて」というタイトルの短いセクションを含めました。このセクションでは、特に TDD、BDD、および ATDD に基づくいくつかの異なるアプローチについて説明したいと考えています。
私はBDDにある程度精通しています（SpecFlowで遊んだことがあります）が、ATDDを読んだ後、非常に似ているように聞こえます。BDD と ATDD は、本質的に同じプロセスの 2 つの名前に過ぎませんか?「ユビキタスな」言語で動作を文書化し、自動化された受け入れテスト スイートを生成し、受け入れテストに合格しますか?
私は基本的にギシュの投稿に同意しますが、同意できない点がいくつかあります。IMHO セクションでは、Rachel Davies らによって開発されたユーザー ストーリー仕様として BDD 仕様を提示しています。
BDD 仕様は指定されています... いつ... そのとき... のように
ユーザーがログインしている場合、ユーザーが x をクリックすると、Y が表示されます。
これは、条件、アクション、および期待に関するものであり、BDD の中核です。
ATDD は、gishu が示唆するように、実行可能な受け入れ基準として実装された受け入れテスト仕様を使用して開発を推進するプラクティスです。BDD 形式の仕様は、必須でも「ベスト プラクティス」でもありません。ただし、実際には、作業が満足に行われ、要件を満たしていることを確認する方法に思考と言語を集中させるのに効果的です。
BDD は特に TDD に基づいているわけではないことに注意してください。ATDD は、開発が完了する前に行われるテストであるという点で、大まかに TDD に基づいています。さらに、開発者の作業ではなく、プロジェクトの全体的な方向性と検証に焦点を当てています。ATDD は、より高いレベルの要件が作成されている発見フェーズでうまく機能するという点で、ストーリー マッピングとうまく調和しています。
BDD（Dan North、Dave Astels、Dave Chelimskyなど）は、配信プロセス全体をアジャイルにする運動です。
とは言うものの、BDDを実行するチームは、ATDDの手法、つまり受け入れ基準の実行可能な仕様から開始するプロセスを採用することになります。ポイントを伝えるのに効果的なグラフィックは、ATDDがTDDの内部サイクルをラップする場所です。
ATDDは、開発前に実行可能受け入れ基準から開始し、それを使用して基盤となるコードベースの設計を形成する方法にすぎません（TDDによく似ていますが、より分厚いレベルです）。
以下は完全に意見であり、完全に正確ではない可能性があり ます。ATDDを実行している可能性がありますが、BDDを実行していない可能性があります。
たとえば、自動受け入れテストを書いている可能性がありますが、それは読み取り可能ではありません。意図を伝えていません。自動化された「回帰」テストの包括的なスイートを作成している可能性がありますが、システムが何を実行するのか、どのように機能するのかはわかりません。
XDoesYをテストする
BDDはそれを次のように指定します
StakeHolderとして、XはYを実行して、Zを実行できるようにする必要があります。
最後に、主な違い（発生する可能性はありますが、発生する必要はありません）は、ATDDがアクティブな開発+回帰のターゲットとして機能する包括的な自動スイートに変わる可能性があることです。BDDは、将来の建設的な会話を可能にする実行可能な例を介して、問題ドメインとソリューションドメイン間の共有言語+生きたドキュメントに針をさらに移動することをお勧めします
私は何もないと言うでしょう。私の最初の仮定は、ATDD、BDD、例による仕様、アジャイル受け入れテストなどはすべて同じことを意味するということです。誰かがこれらの用語を別々のことを意味するように使用する場合、そのコンテキストでの違いをより適切に説明できます。