私は、ダンノースがBDDを考案する意図の1つとして、語彙をテストドメインの複雑さから遠ざけることを知っていました。しかし、外部からのアプローチを実装するには、嘲笑された振る舞い（または、好きな場合は、スタブされた振る舞い）をいくらか理解する必要があるようです。北はthis videoに、私が最も外側のドメインオブジェクトから始め、内向きに作業すると、共同作業者を発見して後で適切な実装に置き換えるときに協力者を模倣すると示唆しています。最終的には、私は一連のエンドツーエンドのテストで終わります。BDDで模擬する方法
Martin Fowlerは、TDDの2つのキャンプを定義したときには、this blog postで少し違ったように見えました。「可能な限り実際のオブジェクトとモックを使用するクラシックTDD」と、 。彼はBDDが後者に向かって傾いているのを見た。つまり、機能の開発が終わった時点で、「模擬的な」アプローチは実際のテストにモックを残すでしょう（BDDディスカッションでその言葉を使用するのはごめんなさい）。
公平で、両方の材料は古く、BDDがユニットレベルと受入れレベルの間で適用される間に進展するにつれて物がより明瞭になったのかもしれません。
私の話が完全に終わったら、私のシナリオは実際にどのくらいのエンドツーエンドテストが必要なのでしょうか？ North explains BDDには抽象化が必要です。たとえば、ログインの動作をテストしているとき、私のシナリオでは、ログインプロセスの意味を詳しく説明します。しかし、が必要であるが、ログインではない他のシナリオを実行しているとき、私はこれらのステップを何度もやり直す必要はありません。私は簡単に抽象化したいと思う "私はログインしている"と言うので、私は他の行動を実行することができます。
抽象化への私のアプローチは、私が特定の共同作業者を模擬する（または「テストダブル」を提供する）ことであり、いくつかのシナリオでは他のシナリオよりも多くを使用することがあります。たとえば、DBやメールサーバーなどの外部リソースを常に模擬していますか？
おそらく私は間違った質問をしています。 BDDは、すべてのコミュニケーション、フィードバックサイクルの短縮、およびあなたが知らないものの発見です。私たちが実際に関心を持っている行動が実際に機能している限り、無関係な疑問であるかもしれません。私は他の人のアプローチがここにあるのは不思議です。