【发布时间】：2017-09-01 20:37:36
【问题描述】：
什么是集成测试使用 ASB 的系统的合适方法？使用 Kafka 之类的东西并使用 docker-compose，我可以启动两个通过 Kafka 进行异步通信的服务。有没有办法用 ASB 做类似的事情？如果不是，常见的集成测试模式是什么？
【问题讨论】：
标签： azure docker-compose integration-testing azureservicebus
【发布时间】：2017-09-01 20:37:36
【问题描述】：
Service Bus 的定价模型为12.5 million operations per month included for free。除此之外，每发送数百万条消息不到一美元。使用这些类型的服务，作为集成测试的一部分，您应该可以轻松地以绝对零成本启动和拆除实例。
例如，NUnit 提供了 [OneTimeSetup] 和 [OneTimeTearDown] 方法，您可以将它们用作集成测试套件的一部分，以提供并随后删除服务总线实例。
【讨论】：
-
我没有考虑过启动“整个”服务总线实例，但这似乎是一种合理的方法。坦率地说，成本不是问题，主要是我希望隔离测试，这样它们就不会相互干扰，我认为这种方法，正如另一种建议的回答一样，符合要求。
-
如果您希望执行真正的“集成测试”而不是模拟您对服务总线的依赖的单元测试，那么这是您最好的做法。
-
感谢企业留言，但如果去开会，反馈一致：测试会崩溃，代码会循环，留言数会暴涨，账单会爆炸。微软方面的工作正在进行中：github.com/Azure/azure-service-bus/issues/223
遗憾的是，我认为Azure Storage Emulator 还不支持服务总线，但您可以将功能提取到接口中，然后编写一个假 ASB 并使用它，或者让接口使用模拟器中的队列。如果您想使用实际的 ASB 并且不介意产生成本，您可以使用名称的 guid 启动一个新的，或者如果创建临时队列或主题/订阅并使用名称的 guid，然后将其全部撕掉完成后放下。
也许并不理想，但它为您提供了一些选择。也许如果您分享更多关于您使用 ASB 的详细信息，我们可以提供更好的解决方案。
【讨论】：
-
这听起来是个不错的主意，是我正在考虑的一些事情的具体例子。谢谢！
-
这些听起来像是单元测试，而不是集成测试。根据定义，集成测试应该针对实际服务而不是模拟运行。
-
@JesseCarter，我明白你在说什么，我不反对。随着我深入研究，我可能会改变我的观点，但此时我对两个或多个服务之间的交互以及它们如何相互“反应”感兴趣。我同意不使用“真实”的 ASB 实例会降低对测试的信心。
-
@ksigmund 测试服务及其交互之间的交互并没有错，这通常被称为“单元测试”。我只是根据您想要运行实际集成测试的标准来回答，这意味着不同的东西。我个人会尝试在实际项目中实现这两种类型的测试作为适当测试覆盖的一部分
-
JesseCarter，单元测试在技术上是测试一个单元或“被测系统”。任何测试两个或更多组件之间的集成的测试都是集成测试。你在谈论一个完整的集成测试。所有这些都可能有价值，但由@ksigmund 决定什么对他来说最实用。就我个人而言，我会保留一个 ASB 用于测试和动态创建/删除队列和主题/订阅。我还喜欢在设置时清理它们，以便在测试运行后，如果需要，我可以手动检查死信队列等。
在 docker hub 中有一个 Azure Storage Emulator Docker Image。使用时，请记住必须使用 Windows 仿真：
给定的图像可以在 docker compose 中使用：
version: '3.7'
services:
azure_sb:
container_name: azure_sb
image: microsoft/azure-storage-emulator
tty: true
restart: always
ports:
- "10000:10000"
- "10001:10001"
- "10002:10002"
对于测试或开发用途，考虑使用它的 Lightway 版本，即 Azurite link to doc
version: '3.7'
services:
azurite:
container_name: azurite
image: mcr.microsoft.com/azure-storage/azurite
tty: true
restart: always
ports:
- "10000:10000"
- "10001:10001"
【讨论】：