4

プロジェクトにキャッシュレイヤーを追加しました。キャッシュを操作するテストメソッドをユニット化できるかどうか疑問に思います。または、レイヤーのロジックをテストするためのより良い方法はありますか？

プロセスを確認したいだけです。例：

1-アイテムがキャッシュにない場合、メソッドはデータベースにヒットする必要があります

2-次回メソッドはキャッシュを使用する必要があります

3-データベースに変更が加えられた場合、キャッシュをクリアする必要があります

4- databseから取得したデータがnullの場合、キャッシュに追加しないでください

メソッドに配置したロジックが期待どおりに機能していることを確認したいと思います。

4

1 に答える 1

3

キャッシュはサードパーティのキャッシュだと思いますか？もしそうなら、私はそれをテストしません。それ以外の場合は、他の誰かのコードをテストしています。

このキャッシングが非常に重要であり、テストする必要がある場合は、統合テストまたは受け入れテストを行います。つまり、問題のページ/サービスにアクセスして、その方法でコンテンツを確認します。テストしたいものの定義そのものにより、これは単体テストではありません。

反対に、キャッシュが自分でロールしたものである場合は、機能を簡単に単体テストできます。キャッシュの動作をテストするために、検証ベースのテストをチェックアウトすることをお勧めします。実際にチェックするのではなく、キャッシュに追加/削除されます。これを達成する方法については、モックをチェックしてください。

モックオブジェクト（または同様のもの）を介して動作をテストするには、次のようにします-コードは異なりますが。

class Cacher
{
    public void Add(Thing thing) 
    {
         // Complex logic here...
    }

    public Thing Get(int id) 
    { 
        // More complex logic here...
    } 
}

void DoStuff() 
{
   var cacher = new Cacher();
   var thing = cacher.Get(50);
   thing.Blah();
}

上記の方法をテストするために、私はモックを使用したテストを行いCacherます。これを実行時にメソッドに渡すか、コンストラクターに依存関係を注入する必要があります。ここから、テストcache.Get(50)は呼び出されたことを確認するだけです。アイテムが実際にキャッシュから取得されるわけではありません。これは、実際に何かをキャッシュ/取得しているのではなく、キャッシャーの使用方法の動作をテストしています。

その後、単独でCacherの状態ベースのテストにフォールバックできます。たとえば、アイテムを追加/削除します。

前に言ったように、これはあなたがやりたいことによってはやり過ぎかもしれません。ただし、この種のテストを保証するには、キャッシングが十分に重要であるとかなり確信しているようです。私のコードでは、モックオブジェクトを可能な限り制限しようとしていますが、これは有効なユースケースのように聞こえます。

于 2012-09-16T12:37:36.060 に答える