WCF 数据服务：模拟 OperationContext

发布于 2024-10-17 19:16:01 字数 313 浏览 3 评论 0原文

我们想模拟 OperationContext 类以进行测试。我们正在使用“模拟”。但 OperationContext 是一个密封类，不能被模拟。因此，我们尝试创建一个虚拟 OperationContext 对象。但是 OperationContext 构造函数采用 IContextChannel 作为参数。我们想知道一种获取 IContextChannel 的方法，以便将其传递给 OperationContext 构造函数。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

请恋爱 2024-10-24 19:16:01

一般建议是不引用wcf实现wcf服务。

如何执行此操作的示例位于 http://marcin。 floryan.pl/blog/2012/01/do-we-really-need-wcfmock

我们将对OperationContext的引用替换为对
操作响应。操作响应应定义为
接口，可以像下面一样注入到构造函数中
存储库在给出的示例中。我们的测试方法现在变成了
稍微短一些，更具可读性。

以及在 http://blogs.msdn.com/b/ ploeh/archive/2006/12/04/integrationtestingwcfservices.aspx

让我们暂时考虑一下执行授权的需要。你
可以直接在每个操作中检查OperationContext.Current
操作实现，但这会引起混合问题（业务
操作中实现的逻辑与授权混合在一起）。
正确的方法是提供一个派生自的类
ServiceAuthorizationManager，并配置服务以使用它
授权类。这将使您能够继续进行单元测试
你的操作实现，但显然，你还需要测试
授权管理器本身，事实证明集成
测试是完成此任务的最简单方法。

如果您仍然需要模拟，请遵循 http://blogs.msdn.com/b/ploeh/archive/2008/06/28/unit-testing-duplex-wcf-services.aspx

您所要做的就是替换通话
toOperationContext.GetCallbackChannel 具有抽象的东西。在
.NET 3.5，最简单的抽象是Func，它具有相同的
签名，但如果您使用 .NET 3.0，则始终可以定义类似的
您自己的委托类型。

或者，作为最后的手段，您可以使用WCFmock

#if DEBUG
     using WebOperationContext = System.ServiceModel.Web.MockedWebOperationContext;
#endif

例如，如果您想在中使用模拟版本，这很有用
开发，并且始终是生产中的 WCF 版本。就这样吧，你
根本不需要触及您现有的服务实现，一旦
您定义了该别名，该服务已准备好进行测试

来自 http://blog.gfader.com/2010/08/how-to-unit-test-wcf-service.html

对OperationContext.Current.Channel.SessionId的所有调用都得到
被 MockedOperationContext 拦截，但仅在您的测试中
模拟OperationContext。在你正常的环境中
MockedOperationContext 充当真实OperationContext 的代理。

The general recommendation is to implement wcf services without referencing wcf.

Examples how to do it are in http://marcin.floryan.pl/blog/2012/01/do-we-really-need-wcfmock

We replaced a reference to OperationContext with a reference to
operationResponse. The operationResponse should be defined as an
interface and can be injected in the constructor just like the
repository is in the example given. Our test method now becomes
slightly shorter and more readable.

And in http://blogs.msdn.com/b/ploeh/archive/2006/12/04/integrationtestingwcfservices.aspx

Let's, for a moment, consider the need to perform authorization. You
could inspect OperationContext.Current directly in each of your
operation implementations, but that would be mixing concerns (business
logic implemented in the operation mixed together with authorization).
The correct way would be to provide a class deriving from
ServiceAuthorizationManager, and configure the service to use this
class for authorization. This would allow you to keep unit testing
your operation implementations, but obviously, you also need to test
the authorization manager itself, and it turns out that integration
testing is the easiest way to accomplish this task.

If you still need mock follow a recommendation from http://blogs.msdn.com/b/ploeh/archive/2008/06/28/unit-testing-duplex-wcf-services.aspx

All you have to do is to replace the call
toOperationContext.GetCallbackChannel with something abstract. On
.NET 3.5, the easiest abstraction is Func, which has the same
signature, but if you are on .NET 3.0, you can always define a similar
delegate type of your own.

Alternatively as a last recourse you can use WCFmock

#if DEBUG
     using WebOperationContext = System.ServiceModel.Web.MockedWebOperationContext;
#endif

This is useful for instance, if you want to use the mocked version in
development, and always the WCF version in production. That's all, you
do not need to touch your existing service implementation at all, once
you defined that alias, the service is ready to be tested

From http://blog.gfader.com/2010/08/how-to-unit-test-wcf-service.html

all your calls to OperationContext.Current.Channel.SessionId get
intercepted by MockedOperationContext, but only in your tests you are
mocking the OperationContext. In your normal environment that
MockedOperationContext acts as a proxy to the real OperationContext.

回复收藏 0 原文