はじめに

前回は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のフィードバックループが分かりやすいです。この図を見ると分かる通り、失敗する受け入れテストを実装することが前提です。

図C.2 TDDにおける内側と外側のフィードバックループ
(『実践テスト駆動開発』図1-2に基づき作成)

なお、「失敗するユニットテストを書く→テストを通るようにする→リファクタリングする」という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によって生み出された用語です。

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

Gojko Adzicは著書『Specification by Example: How Successful Teams Deliver the Right Software』の執筆を通じて、要件の発見が重要であると強調したかったと思われます。

SbEとBDDの違い

SbEとBDDは、現在の対象ドメインの状態のどの部分に対応するプラクティスなのかで違いがあります。(以下の表はLiz Keoghが定義した内容を元に作成)

BDDはLv.4やLv.5のように、まだ明確な答えが誰も分かっておらず、模索していく段階から効果を発揮します。

一方、SbEはLv.3のように、誰かが行っているが、それを仕様として表現できていない段階について注目しています。

違いは何となく分かったが…

ここまででBDDとATDDとSbEの違いについて説明してきました。

しかし、現実世界において本当に使い分けて利用しているのでしょうか?

ここで、Liz Keoghが2011年に自身のブログで書いた言葉を紹介します。

BDDと広義のTDD(もしくはATDD)の違いは呼び方です。「BDD」という単語を用いる方が役立つ人もいれば、「TDD(もしくはATDD)」という単語を用いる方が役立つ人もいるというだけです。

Liz Keogh, lunivore

Lizは、この言葉を書いた数年後に、本記事で紹介した「SbEとBDDの違い」の定義を言語化しています。

しかし最近では、ATDDとBDDの違いが少なくなっているかもしれません。ATDDを行っている人たちがBDDで大事にしている「会話」や「共有言語」も大切にしていますし、BDDを行っている人たちも自動化を疎かにしようとは思っていません。普段の業務の中で「ATDD」と呼んでいても「BDD」と呼んでいても、本連載に書いている考えを大切にして進めてもらえればと思います。

次回予告

今回はBDDとATDDとSbEの違いについて説明しました。

次回はBDDの考え方により焦点を当て、BDDで勘違いされやすい部分について説明します。

連載一覧

TDDとBDD/ATDD(1) TDDはテスト手法ではない
TDDとBDD/ATDD(2) 2種類のBDD
TDDとBDD/ATDD(3) BDDとATDDとSbE
TDDとBDD/ATDD(4) ツールとしてのBDDとプロセスに組み込まれたBDD
TDDとBDD/ATDD(5) BDDのプロセスその1「発見(Discovery)」と実例マッピング
TDDとBDD/ATDD(6) BDDのプロセスその2「定式化(Formulation)」とBRIEFの原則
TDDとBDD/ATDD(7) BDDのプロセスその3「自動化(Automation)」

SHARE

  • facebook
  • twitter

SQRIPTER

風間 裕也(かざま ゆうや):ブロッコリー

B-Testing

記事一覧

電気通信大学大学院修士課程修了。
B-Testingを開業し、「どのようにテストを考えればよいか」を社内外問わずエンジニアに日々お伝えしている。


【社外コミュニティ活動】
・WACATE(ソフトウェアテストをテーマとしたワークショップ)実行委員長
・JaSST Review(ソフトウェアレビューシンポジウム)実行委員長


【翻訳活動】
・Agile Testing Condensed(翻訳)
・A Practical Guide to Testing in DevOps(共訳)
・The BDD Books - Discovery(翻訳)

RANKINGアクセスランキング
#TAGS人気のタグ
  • 新規登録/ログイン
  • 株式会社AGEST
NEWS最新のニュース

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST