22

BDD を考案する際の Dan North の意図の 1 つは、語彙をテスト ドメインの複雑さから遠ざけることであったことを私は知っています。ただし、outside-in アプローチを実装するには、モック化された動作 (または必要に応じてスタブ化された動作) を理解する必要があるようです。North氏はこのビデオで、最も外側のドメイン オブジェクトから始めて内側に向かって作業を進めると、共同作業者を発見したら嘲笑し、後で適切な実装に置き換えることを提案しています。最終的には、一連のエンド ツー エンド テストが完成します。

Martin Fowler は、このブログ投稿で、TDD の 2 つの陣営を定義したとき、それを少し違った見方をしているように見えました。可能な場合は実オブジェクトを使用し、必要な場合はモックを使用する「クラシック TDD」と、ほとんどの状況でモックを好む「モックスト TDD」です。彼は、BDD は後者に向かう傾向があると考えていました。つまり、機能の開発の最後に、「モックイスト」アプローチは実際のテストにモックを残すことになります (BDD の議論でその言葉を使用して申し訳ありません)。

公平を期すために、どちらの資料も何年も前のものであり、BDD がユニット レベルでの適用と受け入れレベルでの適用の間の線に沿って進化するにつれて、状況がより明確になった可能性があります。

しかし、コミュニティに対する私の質問は、基本的には次のとおりです。私のストーリーが完成したとき、私のシナリオは実際にどの程度のエンド ツー エンドのテストを行う必要がありますか? North氏は、BDD には抽象化が必要であると説明しています。たとえば、ログイン動作をテストしている場合、シナリオではログイン プロセスの意味を詳しく説明します。ただし、ログインが必要であるがログインに関するものではない他のシナリオを実行している場合、これらの手順を何度も実行する必要はありません。「ログインしていると仮定して」という簡単な抽象化が必要なので、他の動作を実行できます。

したがって、抽象化への私のアプローチは、特定の共同作業者をモックする (または「テストダブル」を提供する) ことになるようです。シナリオによっては、それらを他のものよりも多く使用する場合があります。たとえば、DB やメール サーバーなどの外部リソースを常にモック アウトしますか?

おそらく私は間違った質問をしています。BDD は、コミュニケーション、フィードバック サイクルの短縮、および知らないことの発見に関するものです。私たちが興味を持っている動作が実際に機能する限り、おそらく何をモックして何をモックしないかは無関係な質問です。ここで他の人のアプローチがどうなっているのか興味があります。

4

3 に答える 3

8

私にとって BDD は、私が正しいものを構築したことを確認できるようにしてくれます。つまり、アプリケーションを実際のデータベースにプラグインして実際の UI を使用すると、正しく動作するはずです。それはあなたが話している端から端までです。

ここで、アプリケーションをメモリ内ストレージに接続し、その API レベル (UI のすぐ下) を介してアプリケーションと通信するとします。まったく同じように動作することを期待しています。

ビヘイビアとは何を意味するのか、BDD を実行するときに関心のあるビヘイビアとは何かを明確にする必要があります。

私の場合、ユーザー ストーリーから始めてシナリオを書く場合、主にアプリケーション API、サービス レイヤー、ドメイン エンティティ、ヘルパーなどを通過する動作に関心があります...主にあまり関心がありません。 UIでもデータベースでも何が起こるか。本当の肉は、サーバー側で書かれたすべてのコードです。それが私が興味を持っている動作です。そのように考えるなら、UI と DB を取り除くのは理にかなっています。UI の予想される動作は、アプリケーションが提供するデータを表示することです。UIはばかげたものです。DB の期待される動作は、アプリケーションが提供または必要とするエンティティを格納および取得することです。それもまた、本当にばかげたことです。他のすべては、そこにすべてのスマートさがあり、私が責任を負っています。

そのため、UI を使用せずに、リポジトリのインメモリ バージョンを使用して BDD シナリオを喜んで実行します。そこから得られるボーナスは、非常に高速で、的を絞った、保守可能なテストです。

UI と DB に関しては、JavaScript 単体テストを記述して動作をテストします。現在、一部の UI には、表示と非表示を切り替える表示ロジックが多数ありますが、そのような動作は、私のユーザー ストーリー bdd の動作とは異なります。シナリオ (UI について話すべきではありません)。

DB については、実際のリポジトリが DB で読み書きできることを確認するためだけに統合テストを作成します。

そして最後に、いくつかのエンド ツー エンド テストを作成して、すべてが接続されたときに問題がないことを確認します。

于 2012-10-05T21:24:25.353 に答える
7

重要なのは、BDDのB-動作に焦点を当てることだと思います。

現時点では、UI要素を無視して永続化レイヤーをモックアウトする傾向があります-これらのレイヤーにはビジネスロジックがほとんどありません(既存のレイヤーとDBを使用してオブジェクトモデルをUIまたはDBに直接バインドする傾向があります)徹底的にテストされたフレームワーク)。

例として、私が構築していた最近の(単純な)WPFアプリケーションでは、受け入れテストでViewModelをアプリケーションのエントリ/外部ポイントとして使用し、データリポジトリからすべてがモックされました。アプリケーションのすべてのルールとロジックは、2つの間のどこかに存在していました。実際、これらは、指定してテストする必要のあるアプリケーションの動作です。

于 2012-05-25T15:22:04.117 に答える
1

何をモックするかは、アーキテクチャによって異なります。MVVM の場合、モデルをモックしてビューモデルをテストできます。MVP の場合、ビューやモデルをモックしてプレゼンターをテストできます。単体テストではなくエンド ツー エンドのテストを作成する場合は、ビュー モデル/プレゼンターからアプリケーションの反対側 (サービス/データベース レイヤー) までテストします。

于 2012-05-25T17:15:15.527 に答える