8

私はいくつかの単体テストを書いていますが、モックを作成するのが有利かどうか疑問に思っていCacheます。

現在、私のテストでは、をモックしてHttpContextBaseカスタムでラップしていますHttpContextFactory：

var mockedHttpContextBase = new Mock<HttpContextBase>();

IHttpContextFactory httpContextFactory = new HttpContextFactory 
{ 
     Current = mockedHttpContextBase.Object 
};

私のコードが を消費するときは、IHttpContextFactory何かを行う前にキャッシュが null かどうかを確認します。

var cache = _httpContextFactory.Current.Cache;

Func<SomeReturnType> doSomeWork = () => _foo.someMethodIExecute(param1,param2);

return cache != null ? cache.GetOrStore("doSomeWorkCacheKey",doSomeWork, 900) 
                     : doSomeWork.Invoke();

使用するたびにこのようにキャッシュが null であることを確認するのは正しいですか、それとも単体テストを実行するときに null にならないように、テストでもキャッシュをモックしますか?

4

2 に答える 2

14

少し検索した後、単体テストを書くときHttpRuntime.Cacheの代わりに使用できるようです。System.Web.Caching.Cache

そのような：

var mockedHttpContextBase = new Mock<HttpContextBase>();
mockedHttpContextBase.Setup(m => m.Cache).Returns(HttpRuntime.Cache);

キャッシュは絶対にあってはなりませんnull(そうであれば適切な例外です) ので、コードから null 参照チェックを削除できます。

于 2012-04-30T13:12:28.163 に答える
4

コードがキャッシュを使用できると想定し、アクセスする前にチェックを実行する場合（現在のように）、キャッシュアクセスnullごとに2つの単体テストを行う必要があります。

  • キャッシュが存在し、アイテムが保存および取得されます（GetOrStore呼び出しのチェック）
  • キャッシュがnullであり、デリゲート呼び出しをアサートするだけです

これが一般的なパターン（nullチェック）である場合は、キャッシュの依存関係が必要になるたびに2つのテストを行う代わりに、Null Object Patternにラップして一度テストし、後でモックできる依存関係としてNOPを使用することをお勧めします。

編集：キャッシュの「モック」の例

var cache = new Cache();
// Add takes more parameters; fill whatever is necessary to make it work
cache.Add("doSomeWorkCacheKey", doSomeWork, ...);
var mockedHttpContextBase = new Mock<HttpContextBase>();
// tell your mock to return pre-configured cache
mockedHttpContextBase.Setup(m => m.Cache).Returns(cache);

IHttpContextFactory httpContextFactory = new HttpContextFactory 
{ 
    Current = mockedHttpContextBase.Object 
};
于 2012-04-30T11:38:11.877 に答える