TDDとBDD/ATDD(3)　BDDとATDDとSbE

はじめに

前回は2種類の振る舞い駆動開発（Behavior Driven Development、以下BDD）としてspecBDDとscenarioBDDについて紹介しました。

今回は、BDDと同じようにTDDの発展として語られる受け入れテスト駆動開発(Acceptance test–driven development、以下ATDD)や実例による仕様(Specification by Example、以下SbE)について説明します。

受け入れテスト駆動開発(ATDD)

受け入れテスト駆動開発(ATDD)は、書籍『BDD in Action: Behavior-driven development for the whole software lifecycle』によると、「Story Test-Driven Development」という呼び名で1990年後半から手法として存在していました。その後2003年に、Kent Beckが著書『Test Driven Development: By Example（邦訳：テスト駆動開発）』の中で言及しています。この書籍の中では、「アプリケーションレベルのテスト駆動開発（ATDD:application test-driven development）」と紹介されていましたが、現在広く知られている「受け入れテスト駆動開発(Acceptance test–driven development)」とほぼ同じ概念と思われます。

ATDDは、Featureを実装する前に、Featureの受け入れ基準となる自動テストを作成する手法です。

ATDDとBDDの違い

ATDDとBDDは関心ごとが違います。

ATDDは、受け入れ基準に注目し、自動化することに重きを置いています。ATDDについては書籍『テスト駆動開発』の付録Cに書かれているATDDのフィードバックループが分かりやすいです。この図を見ると分かる通り、失敗する受け入れテストを実装することが前提です。

なお、「失敗するユニットテストを書く→テストを通るようにする→リファクタリングする」というTDDに該当する内側のフィードバックループの部分（図の緑囲み部分）を「狭義のTDD」と呼び、「失敗する受け入れテストを書く→受け入れテストを通るようにする（狭義のTDDの部分）」というATDDに該当する外側のフィードバックループの部分も含めて「広義のTDD」と呼ぶことがあります（図の赤囲み部分）。

つまり、「TDDの考え方の対象が広がったものがATDDである」という捉え方です。^※1

一方、BDDは実装できる（自動化する）ことが前提ではありません。会話に重きを置き、共有言語(Shared Language)を増やしていくことを大切にしています。

結果として自動化したスクリプトを書くことができるかもしれませんが、自動化できなくても構わないと考えています。詳しくは、第4回（次回）以降の記事で書いていく予定です。

また、対象とする抽象度の幅にも違いがあります。ATDDはその名の通り、（特にユーザー視点での）受け入れレベルが対象です。一方、BDDは振る舞いに着目している限り、受け入れテストだけでなく、統合レベルでも活用することができます。

※1 正確に言うと、広義のTDDこそが本来のTDDの思想でした。しかし、狭義のTDDの部分を「TDD」と考える人が多かったため、わざわざATDDという言葉を用いて表現することになったという経緯があります。

実例による仕様(SbE)

実例による仕様(SbE)は、2002年にMartin Fowlerによって生み出された用語です。

基本的には、その名の通り「実例を用いて仕様を表現しよう」というコンセプトです。