工作流程系统中的单元/自动化测试
您是否对像 K2 这样的复杂工作流程系统进行自动化测试？
我们正在构建一个在 Sharepoint 2007 和 K2 之间进行广泛集成的系统。 我什至无法想象从哪里开始自动化测试，因为工作流程涉及多个用户与 Sharepoint、K2 工作流程和自定义网页进行交互。
有人在像K2这样的工作流服务器上做过自动化测试吗？ 付出的努力是否超过其价值？
Do you do automated testing on a complex workflow system like K2?
We are building a system with extensive integration between Sharepoint 2007 and K2. I can't even imagine where to start with automated testing as the workflow involves multiple users interacting with Sharepoint, K2 workflows and custom web pages.
Has anyone done automated testing on a workflow server like K2? Is it more effort than it's worth?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我在测试工作流程繁重、基于 MOSS 的应用程序时遇到类似的问题。 我们案例中的工作流程基于 WWF。
我的想法是模拟几乎所有无法通过单元测试控制的内容 - 文档存储、身份验证、用户权限和操作、共享点工作流程的特定于共享点的部分（这些模拟应该经过彻底测试以反映真实组件的行为） 。
您可以使用控制反转使代码选择在运行时使用哪个组件 - 真实组件或模拟组件。
然后，您可以编写系统范围的测试来测试工作流行为 - 设置您自己的环境，检查工作流引擎的反应方式。 这些测试太大，不能称为单元测试，但它仍然是自动化测试。
这种方法似乎适用于微不足道的情况，但我仍然必须证明它值得在现实世界的工作流程中使用。
I'm having a similar problem testing workflow-heavy MOSS-based application. Workflows in our case are based on WWF.
My idea is to mock pretty much everything that you can't control from unit tests - documents storage, authentication, user rights and actions, sharepoint-specific parts of workflows for sharepoint (these mocks should be thoroughly tested to mirror behavior of real components).
You use inversion of control to make code choose which component to use at runtime - real or mock.
Then you can write system-wide tests to test workflows behavior - setting up your own environment, checking how workflow engine reacts. These tests are too big to call them unit-tests, still it is automated testing.
This approach seems to work on trivial cases, but I still have to prove it is worthy to use in real-world workflows.
解决方案如下我用。 这是运行时的一个简单包装器，允许执行单个活动，简化参数传递，阻塞调用线程直到工作流或活动完成，并转换/重新抛出异常（如果有）。 由于我的工作流程仅通过自定义工作流程服务发送或等待消息，因此我可以模拟该服务以期望来自工作流程的某些消息并向其发布某些消息，在这里我正在为我的 WF 进行真正的单元测试！ 技术的功劳归功于迈克尔·肯尼迪。
Here's the solution I use. This is a simple wrapper around the runtime that allows executing single activity, simplifies passing the parameters, blocks the invoking thread until the workflow or activity is done, and translates / rethrows exceptions if any. Since my workflow only sends or waits for messages through a custom workflow service, I can mock out the service to expect certain messages from workflow and post certain messages to it and here I'm having real unit-tests for my WF! The credit for technology goes to Michael Kennedy.
如果您打算进行单元测试，Typemock Isolator 是目前唯一可以模拟 SharePoint 的工具对象。
顺便说一下，Richard Fennell 正在开发工作流程模拟解决方案这里。
If you are going to do unit testing, Typemock Isolator is the only tool that can currently mock SharePoint objects.
And by the way, Richard Fennell is working on a workflow mocking solution here.
我们今天刚刚编写了一个应用程序，用于监视 K2 工作列表、从中选取某些任务、填写一些数据并提交任务以供完成。 这使我们能够执行自动化测试，查找回归，并在比人们花费的时间少的时间内运行尽可能多的不同工作流程路径。 我想可以编写一个类似的程序来假装是共享点。
至于工作流程项本身的单元测试，我们有一个从 k2 引用的 dll，其中包含我们所有的行规则和处理逻辑。 我们在 k2 工作流程本身中没有任何代码，它都是从这些 dll 中引用的。 这使我们能够轻松地在它们上编写单元测试来测试所有单独的行规则。
We've just today written an application that monitors our K2 worklist, picks up certain tasks from it, fills in some data and submits the tasks for completion. This is allowing us to perform automated testing, find regressions, and run through as many different paths of the workflow in a fraction of the time that it would take people to do it. I'd imagine a similar program could be written to pretend to be sharepoint.
As for the unit testing of the workflow items themselves, we have a dll referenced from k2 which contains all of our line rule and processing logic. We don't have any code in the k2 workflows themselves, it is all referenced from these dlls. This allows us to easily write unit tests on them to test all of the individual line rules.
我已经使用 K2ROM API（如果您使用的是 K2 blackpearl，可能是 SourceCode.Workflow.Client）对 K2 工作流程进行了自动化集成测试。
基本上，您可以在具有已知作品集的测试服务器上启动一个进程（我生成一个 GUID），然后使用管理 API 将其删除。 我编写了像 AssertAtClientActivity 这样的帮助器方法（基本上使用标准调用 ProvideWorkItem）。
对 StartProcessInstance、WorklistItem.Finish 等使用 IsSynchronous 参数，以便相关方法调用在流程实例达到稳定状态之前不会返回。
预计测试会很慢并且偶尔会失败。 这些不是单元测试。
如果您想针对其他系统编写单元测试，您可能需要包装 K2 API。
考虑查看 Windows Workflow 4 和 SharePoint 2010 中的新工作流功能。 您可能不需要 K2。
I've done automated integration testing on K2 workflows using the K2ROM API (probably SourceCode.Workflow.Client if you're using K2 blackpearl).
Basically you start a process on a test server with a known folio (I generate a GUID), then use the management API to delete it afterwards. I wrote helper methods like AssertAtClientActivity (basically calls ProvideWorkItem with criteria).
Use the IsSynchronous parameter to StartProcessInstance, WorklistItem.Finish, etc. so that relevant method calls will not return until the process instance has reached a stable state.
Expect tests to be slow and to occasionally fail. These are not unit tests.
If you want to write unit tests against other systems, you'll probably want to wrap the K2 API.
Consider looking at Windows Workflow 4 and the new workflow features in SharePoint 2010. You may not need K2.