1

Web サービスをセットアップするときに、リポジトリクラスを使用してデータをフェッチし、クライアントに送り返すことができます。サービスによって実行されるロジックを単体テストする必要がある場合は、データベースへの呼び出しを回避するために、いくつかのハードコードされたデータ オブジェクトを返す偽のリポジトリへの参照を挿入することができます。

ただし、クライアント側では、サービス プロキシ経由でこの Web サービスを呼び出す MVC ベースの Web アプリケーションがあるとします。 MVC アプリのロジックを単体テストし、サービスが返すものを表すデータをフィードしたい場合、プロキシ参照を偽造するにはどうすればよいですか? 私の考えは次のとおりですが、これについて 100% の自信があるわけではなく、より簡単な解決策を見逃しているのではないかと思います。

プロキシ インターフェイスをセットアップし (IProxy と呼びましょう)、その 2 つの具体的な実装 (たとえば、ProxyとFakeProxy ) をセットアップし、実行中の状況に適したものを挿入します (ユニット テストを実行する場合は FakeProxy を、実行する場合は Proxy を使用します)。実際の本番アプリケーション)。実際のサービス呼び出しを行わずに単体テスト用のサンプル データを生成するには、偽のプロキシに偽のリポジトリ (上記のサーバー シナリオで使用されているものと同じもの) を実装する必要がありますか? クライアント側コードのテストを支援するために偽のプロキシ クラスを設定する最善の方法がわかりません。

アップデート：

これまでに投稿された回答には同意しますが、すでにその点を考慮しているので、なぜこれを求めているのかを示すサンプル C# コードを提供させてください。プロキシの設計から偽のリポジトリを除外した場合、私の偽のプロキシは次の非常に単純で不自然な例のようになります。

public class FakeCustomerProxy : ICustomerProxy
{
    private List<Customer> Customers;

    public FakeProxy()
    {
        Customers = new List<Customer>();

        Customers.Add(new Customer { Id = 1, Name = "Smith, John" });
        Customers.Add(new Customer { Id = 2, Name = "Johnson, Al" });
        Customers.Add(new Customer { Id = 3, Name = "Thomas, William" });
    }

    public Customer GetById(int customerId)
    {
        return Customers.Where(c => c.Id == customerId).FirstOrDefault();
    }
}

GetById ()メソッドは、必要な顧客情報を取得するために Web サービスを呼び出すのではなく、このクラスに埋め込まれたハードコーディングされた顧客リストから単にそれを返します。これは、私が偽のリポジトリ用に設定したものと実際に似ているため (サービス ロジックのテストを支援するために、非常によく似たコードをサーバー側に設定している場合もあります)、これらのハードコーディングされた顧客を配置することを検討する必要があるかどうかに興味がありました。複数の場所で使用される専用の偽のリポジトリ クラスへの参照。 この偽のプロキシの設計を完全に間違って考えているのでしょうか?

4

2 に答える 2

2

いいえ、偽の Web サービス プロキシ用に偽のリポジトリを設定することは、単体テストには適していないようです。

実際には、1 つの偽物 (プロキシまたはリポジトリ) で十分なはずです。

モックフレームワーク ( MoqやRhino Mockなど) を検討することをお勧めします。モックを使用すると、実装
する必要さえありません。各テストでは、事前定義されたデータを返す、例外を発生させる、渡されたパラメーターを検証するなど、必要に応じて正確に動作するFakeProxy個別の模擬実装を簡単にセットアップできます。IProxy

したがって、テスト用に 1 つまたは 2 つの偽のクラスを実装する必要はありません。

更新:
したがって、ここに 2 つのオプションがあります。

  1. 特定のテストごとに固有の、再利用できない単純なテスト データを用意する。各テストまたはテストのグループごとに、ミニリポジトリ (約 1 ～ 3 アイテム) のようなものをセットアップする必要がある場合があります。

  2. サーバー側とクライアント側の両方のコードに共通する、十分な大きさの再利用可能な偽のリポジトリを用意する。ほとんどの場合、クライアント側のテストとサーバー側のテストでこの偽のリポジトリを使用するには、追加のハーネスをサポートする必要があります。FakeProxyたとえば、クライアント側のコードをテストするには追加が必要です。

これらのオプションを検討し、ケースにより適したものを選択する必要があります。

私の意見では、オプション 1 は単体テストに適していますが、オプション 2 は統合テストに役立つ可能性があります。

于 2013-03-28T15:57:22.133 に答える
0

いいえ、テストでリポジトリ プロキシ接続の実装を繰り返すべきではありません。遅かれ早かれ、プロキシ ファサードとリポジトリの間に何らかのビジネス ロジックが存在するようになり、FakeProxy でサーバー側とクライアント側の 2 回実装する必要があります。

したがって、FakeProxy のモック インスタンスは、呼び出しから生データを返すだけです。

一方、実際の Proxy クラスをクライアント テストにインポートし、テスト用にモック リポジトリをインポートすることもできますが、これは単体テストではなく統合テストであり、クライアント テストでサーバー側のコードを使用する必要があります。常に可能です。

于 2013-03-28T15:56:41.697 に答える