在单元测试期间断言 WF 服务变量的值 [英] Assert the Value of a WF Service Variable During a Unit Test

问题描述

我需要断言工作流服务中变量的值.

I need to assert the value of a variable in a workflow service.

我已经从 CodePlex 下载并使用 Microsoft.Activities.UnitTesting 框架来测试工作流服务端点、返回值和流逻辑 - 但我需要在调用端点后验证变量的值，并且得到回应 - 这可能吗?

I've already downloaded and am using the Microsoft.Activities.UnitTesting framework from CodePlex to test the workflow service endpoint, return values, and flow logic - but I need to verify the value of a variable after calling into an endpoint and getting a response - is that possible?

如果不是，是否有其他类型的解决方法可能有效，但不涉及更改工作流程本身以生成输出参数?因为在生产中我当然不需要.

If it's not is there some other type of workaround that might work that doesn't involve changing the workflow itself to produce an output parameter? Because when in production I certainly wouldn't need one.

谢谢！

更新 2.A

目前使用 stubs 方法而不是 WCF 方法来测试服务.

[TestMethod]
[DeploymentItem(@"TestService\Service1.xamlx")]
public void TestValueOfInteger1AfterStart()
{
    // inject the mocks into the service
    var xamlInjector = new XamlInjector("Service1.xamlx");
    xamlInjector.ReplaceAll(typeof(Receive), typeof(ReceiveStub));
    xamlInjector.ReplaceAll(typeof(SendReply), typeof(SendReplyStub));

    // setup the messages
    var stubExtension = new MessagingStubExtension();

    // enqueue a message for the receive activity using parameters content
    stubExtension.EnqueueReceive(XName.Get("{http://tempuri.org/}IService"), "Start", null);

    // setup the host
    var host = WorkflowInvokerTest.Create(xamlInjector.GetWorkflowService().Body);
    host.Extensions.Add(stubExtension);

    try
    {
        host.TestActivity();
        ...

更新 2.B

所以，经过更多的努力，我发现如果我使用存根，我可以通过反射恢复上下文，而不是使用 WCF 端点进行单元测试.上面是存根单元测试代码的摘录，下面是我用来获取刷新的 ActivityContext 的反射代码.但是，现在我在尝试获取变量的值时遇到以下错误.

有趣的部分是，您可以清楚地看到上下文关联的活动是定义它的活动 - 糟糕的框架只是有点混乱.

...
const BindingFlags bindingFlags = BindingFlags.NonPublic | BindingFlags.Instance;

// recover the WorkflowInstance
var proxy = stubExtension.GetType().GetProperty("InstanceProxy",
                                                bindingFlags).GetValue(stubExtension,
                                                                       bindingFlags,
                                                                       null,
                                                                       null,
                                                                       null) as WorkflowInstanceProxy;

// recover the WorkflowInstance
var fieldInfo = proxy.GetType().GetField("instance", bindingFlags);
var workflowInstance = fieldInfo.GetValue(proxy) as WorkflowApplication;

// recover the ActivityExecutor
fieldInfo = workflowInstance.GetType().BaseType.GetField("executor", bindingFlags);
dynamic activityExecutor = fieldInfo.GetValue(workflowInstance);

// recover the rootInstance
fieldInfo = activityExecutor.GetType().GetField("rootInstance", bindingFlags);
var rootInstance = fieldInfo.GetValue(activityExecutor) as ActivityInstance;

// recover the cachedResolutionContext
fieldInfo = activityExecutor.GetType().GetField("cachedResolutionContext", bindingFlags);
var cachedResolutionContext = fieldInfo.GetValue(activityExecutor) as ActivityContext;

MethodInfo methodInfo = cachedResolutionContext.GetType().GetMethod("Reinitialize", bindingFlags);
methodInfo.Invoke(cachedResolutionContext, bindingFlags, null, new object[]
                                                                   {
                                                                       rootInstance,
                                                                       activityExecutor
                                                                   }, null);

var val = (int)((Sequence)rootInstance.Activity).Variables.First(x => x.Name == "integer1").Get(cachedResolutionContext);
Assert.AreEqual(val, 1, "The integer value of integer1 is not correct.");

推荐答案

您可以使用 AppFabric 跟踪和监视变量.

You could use AppFabric tracking and monitor the variable.

然而，这个问题又引出了一个问题，如果你已经在测试流逻辑和输出，为什么还需要测试 wf 实例的内部状态?

However, the question raises the further question that if you are already testing flow logic and outputs, why do you need to test the internal state of the wf instance?

这篇关于在单元测试期间断言 WF 服务变量的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！