如何使用 NServiceBus 执行集成测试？
我的 Web 应用程序有 2 组服务。一组是 UserService 等业务服务，另一组是 EmailService 等实用服务。业务服务如何连接到实用程序服务是通过NServiceBus。在这种情况下如何进行集成测试？我现在所做的是将集成测试分解为 2 个单元测试。首先是测试业务服务，然后模拟/验证 NServiceBus 发送。第二个单元测试是在实用程序服务上，然后模拟/验证电子邮件发送。正如您所知，这根本不是最佳选择。目前我们有 2 个 NServiceBus 实例——一个作为客户端，一个作为服务器（服务器添加了处理程序）。这在正常的非测试模式下工作（因为客户端位于 IIS 的上下文中，服务器是一个独立的应用程序），但是当我尝试在测试中执行此操作时，似乎我无法运行两个实例？有什么建议吗？
I have Web Application that has 2 sets of services. One set is business services like UserService and another set that is utility services like EmailService. How the business services connect to the utility services is through NServiceBus. How do you perform integration tests in this scenario? What I've done right now is that I broke out the integration test to 2 unit tests. First is testing the business service and then mock/verify out the NServiceBus send. Second unit test is on the utility service and then mock/verify the email sending. As you can tell, this isn't optimal at all. Current we have 2 instances of NServiceBus -- one as client and one as server (server has addition of handlers). This work in normal, non-test mode (since client is under the context of IIS and the server is a standalone app) but when I try to do this in test, it seems like I can't run two instances? Any advice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来您通过模拟对 NServiceBus 的外部依赖来正确地进行单元测试。需要明确的是，我对单元测试的定义是它们不会在代码之外执行任何操作（例如，使用 MSMQ）。对于集成测试，您应该能够完成一些非常简单的事情，证明您能够将消息从一个系统传递到另一个系统，并可能获得预期的最终结果。要进行此设置，您实际上可以从测试装置的设置方法中启动 NServiceBus 客户端/服务器（并在拆卸中处理它们）。它们是 EXE 还是在 IIS 中运行并不重要 - 您应该能够在测试中以编程方式启动/停止它们，即使这意味着调用 Process.Start() 或类似的东西。
或者，如果您的集成测试作为持续集成设置的一部分在构建服务器上运行，则构建脚本可以确保在启动测试之前运行正确的进程，这可能会导致更可重复和更快的结果。使用 TeamCity 和 MSBuild 或 NAnt 的组合，可以很容易地完成这样的事情。
It sounds like you are doing Unit Testing correctly, by mocking out the external dependency on NServiceBus. To be clear, my definition of unit tests is that they don't do anything outside of your code (like, say, using MSMQ). For your integration tests, you should be able to get away with something very simple that proves that you are able to pass a message from one system to the other, and perhaps get the expected end result. To set this up, you can actually launch the NServiceBus client/server from within the setup method of your test fixture (and dispose of them in the teardown). It shouldn't matter whether they are EXEs or run within IIS - you should be able to programmatically start/stop them from within your test even if it means calling out to Process.Start() or something similar.
Alternately, if your integration tests are running on a build server as part of a continuous integration setup, your build script can ensure the proper processes are running prior to even launching your tests, which will likely result in more repeatable and faster results. Using a combination of TeamCity and MSBuild or NAnt it is pretty easy to do something like this.