BDDを使用するときに単体テストを使用する方法は？

私はBDDを理解しようとしています。いくつかの記事を読みましたが、理解したように、BDDはTDDの「次のステップ」です。私は両方とも非常に似ていると思うので、この記事で読むことができるように、TDDからの改良としてBDDが生まれたと言います。素晴らしい、私はアイデアが本当に好きです。

考えられない実用的なポイントが1つあります。BAがシステムが持つすべての予想される動作を書き込む.featureファイルがあります。BAとして、彼はシステムがどのように構築されているのかわからないので、次のように書きます。

+シナリオ1：アカウントにクレジットがあります+

アカウントにクレジットがあることを考えると

そして、カードは有効です

そして、ディスペンサーには現金が含まれています

顧客が現金を要求するとき

次に、口座から引き落とされていることを確認し、現金が支払われていることを確認します

そして、カードが返されることを確認してください

わかりました、これは素晴らしいことですが、システムの多くの部分が連携してそれを実現します（Account obj、Dispenser obj、Customer objなどを考えてください）。私にはこれは統合テストのように見えます。

ユニットテストが欲しいです。ディスペンサーにお金があるかどうかを確認するコードをテストするにはどうすればよいですか？または、現金が分配されますか？または、必要なときに口座から引き落とされますか？ ユニットテストと「BA Created」テストを混在させるにはどうすればよいですか？

行動駆動型開発とテスト駆動型開発は無料ですが、互いを置き換えるものではありません。

アプリケーションの「動作」については、受け入れテストで説明されています。受け入れテストは、BDDによれば、Cucumberで記述された機能とシナリオになります。

各小さなコンポーネントがどのように機能するかについての詳細は、ユニットテストで説明されています。単体テストの結果は、Cucumberで作成したシナリオをサポートします。

車を作るプロセスを想像してください。

最初に、製品チームはアイデアを思いつき、最終的に使用シナリオに要約します。

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

このシナリオは少しばかげているように聞こえますが、製品およびエンドユーザーに焦点を当てた非常に高いレベルの要件です。ドアを開け、キーを回してエンジンを始動するだけで、さまざまなコンポーネントが連携して動作します。この1つのテストでは、車両が正常に動作することを確認するのに十分ではありません。スターター、バッテリー、オルタネーター、キー、イグニッションスイッチをテストする必要があります。これらの各コンポーネントには、独自のテストが必要です。

上記のシナリオは「全体像」テストです。車両の各コンポーネントは、全体で適切に機能することを確認するために、「小さな画像」テストが必要です。

ソフトウェアの構築とテストは、多くの点で同じです。トップダウンでデザインし、ボトムアップでビルドします。エンジンを始動することさえできないのに、なぜドアが上がるのですか？バッテリーがないのに、なぜスターターがあるのですか？

製品チームが受け入れテストを思いつき、Cucumberで具体化します。これにより、「全体像」が得られます。適切なコンポーネントとそれらがどのように相互作用するかを設計し、各コンポーネントを個別にテストするのは、エンジニアリングチーム次第です。これがユニットテストです。

単体テストに合格したら、Cucumberシナリオの実装を開始します。それらが合格したら、製品チームが求めたものを提供しました。

私はBDDを理解しようとしています。いくつかの記事を読みましたが、理解したように、BDDはTDDの「次のステップ」です。私は両方とも非常に似ていると思うので、この記事で読むことができるように、BDDはTDDからの改良として生まれたと言います。

実際、いいえ、BDDはTDDの「次のステップ」ではありません。それはある TDD。または、より正確には、TDDの言い換えです。

BDDの作成者は、TDDはテストに関するものではなく、動作仕様に関するものであることを理解するための主なハードルは、TDDの用語はすべて動作仕様に関するものではなく、テストに関することであることに気付きました。誰かがあなたに「ピンクの象を考えないでください」と言うとき、ピンクの象を考えないようにしようとするようなものです。ただし、ピンクの象でいっぱいの部屋にいると、象、ピンクの象」をあなたの耳に。

そのため、彼らは行動仕様の観点からTDDを言い換えました。「テスト」と「テストケース」は現在「例」、「ユニット」は「動作」、「アサーション」は「期待」などです。

ただし、方法論は同じです。受け入れテスト（「機能」を意味する）で開始し、ユニットテストにズームイン（「例」を意味する）、縮小などを行います。

ユニットテストが欲しいです。ディスペンサーにお金があるかどうかを確認するコードをテストするにはどうすればよいですか？または、現金が分配されますか？または、必要なときに口座から引き落とされますか？ ユニットテストと「BA Created」テストを混在させるにはどうすればよいですか？

TDDで行うのと同じ方法。異なるフレームワーク（例：CucumberやRSpec）または異なる言語（例：CでCプロジェクトのサンプルを作成し、FIT / Fitnesseで機能を作成する）で機能とサンプルを書くことができ、両方に単一の機能フレームワークを使用できます（たとえば、Cucumberでサンプルと機能を書く）または両方に単一のサンプルフレームワークを使用することができます（たとえば、RSpecで両方を書く）。フレームワークを使用する必要さえありません。

単一のフレームワークのみを使用したTDD-done-right（BDDと同一）の例はJUnit自体であり、これにはユニットテスト（例）と機能/統合テスト（機能）が混在し、すべてJUnit自体で記述されています。

ケント・ベックはこれを「ズーム」と呼んでいると思います。高レベルで開始し、詳細に「ズームイン」してから、再度元に戻します。

免責事項：私はBDDの専門家ではありませんが、リンク先の記事に関する私の見解をお伝えしようと思います。

TDDは実装手法です-最初にテストを記述し、次にメソッドを実装し、テストを実行し、リファクタリングし、同じメソッドまたは新しいメソッドのテストを追加します。TDDは、クラス名またはメソッド名の選択方法に関するルールを実際に定義していません。それはあなた次第です。TDDは、「完了したとき」も通知しません。

したがって、新しいメソッドのテストを作成するときはいつでも、メソッド名を選択する必要があります。それがBDDの出番です。上記のシナリオのビジネス用語を使用してメソッド名を選択し、クラスの振る舞い、あなたはBDDをやっています。「さらにテストを追加する必要がありますか」と自問するときはいつでも、BAから与えられたシナリオを見て、必要な部分をすべて完全に実装したかどうかを確認できます。そうでない場合は、さらにテストを追加する必要があります。

また、この記事の著者は、テストの名前を選択するときに、より動作に関連した命名スキームを使用することを提案しています。そのため、各テストケースで始まる命名スキームに依存しないツールでJUnitを置き換えることを提案します「テスト」という名前。私はJBehaveを知りませんが、それがそのツールとJunitの主な違いだと思います。

あなたは一般的に追加されます-また、BDDのシナリオはまた、統合テストのための青写真になります後、あなたがTDDでメソッド名を肉付けしているとあなたはユニットテストの合理的な金額を追加した後。

したがって、私の理解では、TDDはBDDの一部として使用できる手段であり、BDDは適切なテストを作成し、より良い名前を付けるのに役立ちます。