3

私はTDDでもBDDでも経験がありません。はい、既存のコードの単体テストをたくさん作成しましたが、ここでは関係ありません。また、仕事でTDD / BDDを使用することはできませんが、趣味のプロジェクトに挑戦したいと思っています。

現在、TDDとBDDの違いを正しく把握しているかどうかはわかりません。今のところ、BDDは進化したTDDであり、最も特徴的な機能は、TDDよりも高いレベルの抽象化（ユーザーストーリー）で作業できることです。TDDでは、基本的に同じユーザーストーリーを取得しますが、BDDほど明確ではありません。それが正しいか？

ツールに関しては、上記のステートメントが正しいと仮定すると、TDDの場合はTestNGやJUnitのようなものを使用する必要があり、BDDの場合はJBehaveのようなツールの恩恵を受けます。

ここで問題となるのは、最初にTestNGとTDDから始めて、それをある程度成功させてからJBehaveとBDDに移行する必要があるかどうかです。または、これは時間の無駄であり、最初からJbehaveとBDDを使用しようとすることを妨げる理由はまったくありませんか？

アップデート：

私の質問に対する2つの素晴らしい回答を受け取り、そのトピックに関する追加の読書に時間を費やした後、私は見つけた素晴らしい記事へのリンクを追加しないように自分自身を助けることができませんでした。以下のこの質問に対する2つの回答と同じ考えを繰り返しますが、より詳細な情報が含まれている可能性があります。記事の私のお気に入りの部分：

The best way to do that is to leverage BDD and TDD. Here is an approach:

 1. Write requirements as user stories using the BDD grammar/structure.
    Do this collaboratively with the key stakeholders. 

 2. Enter the User
        Stories (feature + scenarios) in a BDD tool. 
 3. Write code to map the
            User Stories to tests.
 4. Write production code using TDD to make the
            tests pass.

ご覧のとおり、BDDはTDDが正しく行われているだけではありません。BDDの語彙だけを使用してTDDを改善することもできますが、それはBDDが提供する利点の一部のみを使用するようなものです。これらの両方の手法の長所を使用すると、「重要なソフトウェア」と「機能するソフトウェア」が得られます。

4

2 に答える 2

3

BDDは、アプリの機能をテストし、ユーザーストーリーで説明されているアプリケーションの指定された受け入れ基準を満たしていることを確認することに重点を置いています。

TDDは、機能単位ごとではなく、クラスごとにテストする、低レベルのコードに集中する傾向があります。

ユーザーストーリーで何を達成したいのか、つまり機能が実行すべきことと実行すべきでないことのリストを列挙するのに十分なアイデアがある場合は、BDDを開始するのに適した立場にあります。そのリストからBDD機能ファイルを作成できます。コードのスクラップを作成する前にこれを行うと、機能について考え、考えを具体化することができます。これは、より簡潔で正しいコードを書くのに役立ちます。

BDDテストを実装するためのツールとしてCucumber-JVMを検討することをお勧めしますが、JBehaveは機能的に類似していると言われています。

最後に、私にとってBDDとTDDは、競合するのではなく、相互に補完する手法です。事前にBDDを実行すると、必要なものを簡単に考えることができます。これにより、必要な低レベルの機能を簡単に考えることができます。ユニットテストを前もって書く方が簡単です。コードを記述したら、一連のテストを実行して、アプリが受け入れ基準を満たしていることを証明できます。

私がBDDを行う方法はこれです：

1）ユーザーストーリーのユーザー受け入れ基準
を調べます。2）これらの各条件をテストするためのテストシナリオを含む機能ファイル（英語）を作成します。
3）機能を実装する
4）Cucumber / JBehaveを使用して、機能ファイルからテストをプログラムで実装する
5）すべてのテストに合格することを確認する

次に、これらのテストのライブラリを維持し、継続的インテグレーションの一部として実行します

機能ファイルには、次のような特定の表現の指示が含まれています。

ユーザーがアプリ
にアクセスした場合、ユーザーが検索リンクをクリックすると
、検索ウィンドウが開き、ユーザーは検索ボックスにXXXと入力し
、Enterキーを押します
。検索結果が表示されます。

于 2012-11-30T13:41:13.317 に答える
1

ほとんどの文献は単体テストとしてTDDに焦点を当てており、受け入れテストとしてBDDに焦点を当てていますが、これがそれらを区別するものではありません。

実装レベルでは、BDDは基本的に言語に特別な注意を払ったTDDです。BDDの習得はそれほど難しくありませんが、チームのコミュニケーションを目的としているため、BDDの価値のほとんどを失うことになります。

JUnitは最もユビキタスなフレームワークであるため、まだ学んでいない場合は、JUnitを学ぶことをお勧めします。TDD / BDDを開始する上で最も難しいのは、最初に書き込みテストを行い、テスト容易性を設計する方法を理解することです。

純粋なTDD/BDDを学習したい場合は、最初に受け入れテスト（実行可能仕様）を作成し、それらに単体テストとコードを実行させます。これはおそらく小さなプロジェクトにとってはやり過ぎですが、良い練習です。

于 2012-11-30T13:34:41.980 に答える