BDD を考案する際の Dan North の意図の 1 つは、語彙をテスト ドメインの複雑さから遠ざけることであったことを私は知っています。ただし、outside-in アプローチを実装するには、モック化された動作 (または必要に応じてスタブ化された動作) を理解する必要があるようです。North氏はこのビデオで、最も外側のドメイン オブジェクトから始めて内側に向かって作業を進めると、共同作業者を発見したら嘲笑し、後で適切な実装に置き換えることを提案しています。最終的には、一連のエンド ツー エンド テストが完成します。
Martin Fowler は、このブログ投稿で、TDD の 2 つの陣営を定義したとき、それを少し違った見方をしているように見えました。可能な場合は実オブジェクトを使用し、必要な場合はモックを使用する「クラシック TDD」と、ほとんどの状況でモックを好む「モックスト TDD」です。彼は、BDD は後者に向かう傾向があると考えていました。つまり、機能の開発の最後に、「モックイスト」アプローチは実際のテストにモックを残すことになります (BDD の議論でその言葉を使用して申し訳ありません)。
公平を期すために、どちらの資料も何年も前のものであり、BDD がユニット レベルでの適用と受け入れレベルでの適用の間の線に沿って進化するにつれて、状況がより明確になった可能性があります。
しかし、コミュニティに対する私の質問は、基本的には次のとおりです。私のストーリーが完成したとき、私のシナリオは実際にどの程度のエンド ツー エンドのテストを行う必要がありますか? North氏は、BDD には抽象化が必要であると説明しています。たとえば、ログイン動作をテストしている場合、シナリオではログイン プロセスの意味を詳しく説明します。ただし、ログインが必要であるがログインに関するものではない他のシナリオを実行している場合、これらの手順を何度も実行する必要はありません。「ログインしていると仮定して」という簡単な抽象化が必要なので、他の動作を実行できます。
したがって、抽象化への私のアプローチは、特定の共同作業者をモックする (または「テストダブル」を提供する) ことになるようです。シナリオによっては、それらを他のものよりも多く使用する場合があります。たとえば、DB やメール サーバーなどの外部リソースを常にモック アウトしますか?
おそらく私は間違った質問をしています。BDD は、コミュニケーション、フィードバック サイクルの短縮、および知らないことの発見に関するものです。私たちが興味を持っている動作が実際に機能する限り、おそらく何をモックして何をモックしないかは無関係な質問です。ここで他の人のアプローチがどうなっているのか興味があります。