2

我需要测试一些依赖于当前上下文的静态方法。现在，我当然可以使用HttpContextWrapper来从我自己的代码中删除这种依赖关系。问题在于我在这些方法中使用的第 3 方 API。他们依赖于HttpContext，所以我对此无能为力。但是，我想做的是HttpContext用我的HttpContextBase.

所以我的代码看起来像这样：

public static bool IsSignedUpUser()
{
    //This calls IsSignedUpUser with the production context
    return IsSignedUpUser(new HttpContextWrapper(HttpContext.Current));
}

public static bool IsSignedUpUser(HttpContextBase context)
{
    HttpCookie objCookie = SomeExternalAPIThatReliesOnHttpContextBeingSet();

    return (objCookie != null)
}

我想做的是：

HttpContext.Current = context; //where context is a mocked HttpContextBase

这样，当第 3 方 API 查找HttpContext查询字符串、cookie 值等时，它不会抛出NullReferenceException.

为什么这不是骗子？

在被引用为欺骗的问题中的代码中，作者看起来完全控制，没有外部依赖。我正在使用依赖于的第三方库HttpContext，我无法更改他们的方法签名以接受HttpContextBase，所以我需要一种方法来分配我的HttpContextBase到HttpContext

如果这是不可能的，并且到目前为止我被引导相信它不是，那么好的答案应该建议如何删除这些依赖项。500 - Internal Server Error 至少有一个好的建议。

4

2 回答 2

4

在我看来，您应该用您注入的自定义接口方法替换对 SomeExternalAPIThatReliesOnHttpContextBeingSet 的调用，然后可以像其他任何方法一样模拟该方法。

于 2013-02-08T21:16:56.140 回答
2

[编辑] 根据@jessehouwing，“痣”现在是“假货”，这应该会改善您的 Google-fu

啊，静态依赖......更糟糕的那种。

这可能是矫枉过正，但我​​可能会考虑使用Moles（或他们重命名的任何东西），这将让您覆盖任何行为，静态的、密封的或其他的；这里有一些链接可以细读：

于 2013-02-08T20:22:32.353 回答