BDDはTDDを置き換えるか、拡張しますか？

Question

BDDはTDDを置き換えますか、または両方を一緒に使用しますか？私は、BDDはユーザーが見ることができるものだけをテストすべきだと読んできました。そのような場合は、ユーザーが見ることのできないサービスメソッドにTDDを使用する必要がありますか？

Answer 1

BDDは、TDDとATDD（およびそれらから派生したもの）の両方を置き換えるものです。

BDD用の初めてのツールJBehaveは、実際にはユニットテストフレームワークJUnitの代用として開始されました。 「テスト」という言葉を使わずに、あなたの（まだ書かれていない）システムの動作を説明し、例を提供することを可能にするという意図がありました。その言葉は、 "テスト"は、あらゆる種類の混乱を引き起こしていた！

差が例と挙動と仕様ワード試験に対しが溶液空間であり、すべての問題空間の言語であるということです。人々は彼らが問題を理解していると思うようになりがちであり、解決策をテストしています。

単語のテストを避けると、人々は問題をより完全に調べるのに役立ちます。これについてはDan North's original articleで読むことができます。

Danは2003/4年にBDDを調査していましたが、当時ビジネスアナリストとして働いていたChris Matts氏に説明しました。クリスは、 "しかし、それは分析のようなものです！"そして、彼らはChrisがシステム全体でどのように分析したか、そしてその事例がどのように分析されたかを調べ始めた。そして、Chrisはそれが行動や成果だけではないことに気づいた。という文脈で。それは、今日私たちが現在知っている（時にはキュウリが存在しなかったためにガーキンとは呼ばれていなかった）全体的な「時、その時」の構文を形成しました。

Danはユニットテストツールの上にシナリオ実行フレームワークを書いてから、RBehaveとしてRubyに移植しました。RBehaveはプレーンテキストになり、Cucumberになりました。その時点で、BDDはATDDの代わりになりました（これは、通常、ユニットテストツールを使用した非常に手続き的なスクリプトで行われていました）。

JUnit、NUnit、または他の種類のユニットテストフレームワークを低レベルで使用しているかどうかは、実際問題ではありません。あなたが行動の例を考え、その例を話しているなら、あなたはBDDをやっています。サンプルを書くことは便利で、自動化することも便利です。そのためJBehaveやCucumberのようなシステムレベルで動作するBDDツールがあります。

開発者とテスターが "テスト"を "example"または "should"に気にせずにマップするのはかなり簡単なので、特定のBDDツールを下位レベルで使用する必要はありません。

「テスト」という言葉を使わずに、人々が会話できるのは簡単です。

クラスのBDDを記述するとき、そのクラスの「ユーザー」は通常は別のクラスです。したがって、システムのユーザーが見ることができるものに基づいてシナリオを作成するのと同じ方法で、別のクラスが見ることができるものに基づいて、より低いレベルの例を記述します。 BDDから出てくるテストはとても良い副産物ですが、会話はラバーダックで行わなければならない場合でも、最も重要な側面です。

Answer 2

BDDはTDDに代わるものではありませんが、私はBDDを補完すると主張します。

それはすべての質問に依存して、これについてのビジネスケアはありますか？

ジョブに適切なツールを使用したいと考えています。つまり、BDDには適しているものもあれば、TDDでうまくいくものもあります。正しく実行されると、BDDとTDDの間の線が非常にぼやけます。それが存在する場合でも。

は、私はそれはあなたの質問にいくつかの追加の光を共有することが、私は「テスト氷山」と呼ばれる概念を議論するブログの記事、 http://www.thinkcode.se/blog/2016/07/25/the-right-tool-for-the-job

を書きました。

そして、@ Lunivoreには、会話から得られる問題の理解に比べて、ツールの選択肢があまり重要でないことに同意します。