振る舞い駆動開発のコミュニティでは古い問いが新しい形式で出現した。すなわち、BDDは受け入れテスト駆動開発の改良版に過ぎないのか。このふたつの方法の違いについて、コミュニティでは様々な議論がされているが、Dan North氏は、TDDは"素晴らしい"のだからこのような議論に注力しないでほしいと要求した。
氏が初めて振る舞い駆動開発を紹介したとき、TDDで一般的に使われている言葉を変えた。テストに関する言葉の代わりに振る舞いに関する言葉を使ったのだ。アジャイルコミュニティにはBDDは単なる"TDDの改良版"ではないかと言う人もいる。現在、Cucumber、JBehave 、そしてSpecFlowのようなツールがBDDのシナリオをサポートするまでになった。これらのシナリオにはユーザの視点から見たシステムやアプリケーションの完全な振る舞いが記述される。つまり、受け入れテスト駆動開発に"Given, When, Then"という言葉を導入したものが振る舞い駆動開発になる。しかし、BDDの扱う領域は以前として不鮮明なままなので、コミュニティでは古くからの問いを再検討している。すなわち、"BDDは何が違うのか。"
"いかにしてBDDをビジネスに売る込むか"と題した講演で、氏はBDDを定義し、その中身を開陳することで、BDDをソフトウエア開発のさまざまな段階や規模にどのようにして適用するのか説明した。
"BDDは第2世代の、外部環境に適用した、プル型の、複数の利害関係者、複数のスケールに対応した、高度に自動化されたアジャイルの方法論です。."
また、氏は後日、よりはっきりとBDDを定義することを約束した。これに対してGivWenZenフレームワークの開発者であるWes Williams氏は次のように答えている。
"その定義は肝心な部分が抜けてしまうと思います。それは私たちは熱心に協力と学習を行っているということです。2005年に'ATDD'を使っていたプロジェクトに従事していたとき思ったのは、私たちの目的はBDDからGiven, When, Thenという言葉を除いたものと同じだということでした。"
初めてBDDを紹介した文書によれば、Dan North氏はよりビジネスに近い言葉を使うことで、"test"という単語と"should"という単語を交換しようと思い立った。Neel Lakshminarayan氏はこのことを取り上げて、
""正しい言葉"を使うことについてもBDDは示唆に富んでいます。これは際立った特徴だと思います。目立たない特徴かも知れませんが、強力です。 ... 今までとは全く異なる問いが頭に浮かぶはずです。すなわち、"どのようにテストするか"ではなく、"どのような振る舞いが意図されているか"という問いです。この違いによって考え方も変わります。その結果、コードの書き方も変わるはずです。"
違いは何なのか。Dan North氏が強調するのは使う言葉が違うということだ。そして、同時に氏はよく考えた上での発見と呼ばれる考え方のなかでBDDを理解することを強調する。よく考えた上での発見は"偶然の発見の反対の考え方"だ。氏はわざと技術や人やプロセスにまつわる無知を取り扱おうとしている。万全の努力をしても無知はつきまとうものだ。一方で氏はコミュニティに対して、BDDとTDDやATDDの改良版の違いを最小にするように要求している。
"I'd like to avoid "BDDはTDDより優れている。なぜなら..."、あるいは"BDDはTDD(as originally envisioned)とは違う。なぜなら..."という言い方は避けたいです。TDDは素晴らしい。TDDの初期の概念は、私がBDDで取り組もうとしていたことそのものの解決策でした。...TDDもBDDも素晴らしい設計をするための唯一の方法ではありません。BDDでは顧客のニーズを理解し、その理解の発生を原動力にしてソフトウエアの開発が進みます。 ... より深い理解を常に求めます。でもKent BeckにTDDとは何なのかと尋ねれば、同じ答えが返ってくるでしょうね。