在微服务环境中测试异步通信
我有一个用于RabbitMQ的应用程序,该应用程序使每个休息流异步,我正在为创建测试而努力,
如何为依赖异步通信的微服务后端应用程序创建测试?有什么工具吗?
谢谢 :)
I have an application with RabbitMQ that makes each Rest flow asynchronous and I’m struggling with creating tests for that
How can I create tests for microservices backend applications that rely on async communication? Is there any tool for that?
Thanks :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这是一个真正的痛苦。异步通信使测试微服务环境更加困难,无法访问状态代码和例外。这样的应用程序的“层”使创建测试变得更加困难。
如果要创建测试,则有一些选择:
1。基于日志的测试
您可以在不同服务中的每个操作中添加日志,然后,您可以从这些服务中获取日志并验证相关数据是否存在。
这种方法存在一些挑战:
例如,没有对日志请求的书面有效载荷,它们
无法验证。
听起来像是创建片状测试的完美方法。
操作的日志,而不是操作本身。因此,
我们不知道该操作是否成功。
2。 DB查询
通过将操作指示保存在DB中,可以在测试期间查询DB以验证是否存在。
这种方法存在一些问题:
同样,就像先前的日志解决方案一样,您正在测试DB对象更新操作,而不是实际操作,这是完全错误的,无法检测到任何实际问题。
3。 基于跟踪的测试,
而不是过度工程应用程序以使其可测试,我建议在工业中弹出的新范式,不需要您的代码工程。这种方式建立在迹线上。
迹线是所有操作的聚合。在称为跨度的跟踪中操作,它代表组件之间的任何通信。
使用可搜索的跟踪,您可以搜索和验证各种跨度
。这很容易接近每个操作,并将其视为整体的一部分,而不是个人动作。
另外,可以自动创建轨迹,而无需开发人员必须决定在哪里插入它们,与日志不同。
您可以阅读有关痕量基础测试的更多信息
This is a real pain. Asynchronous communication makes testing microservices environments much harder, there is no accessibility to the status codes and exceptions. “layers” to applications like that make it harder to create tests.
You have a few options if you want to create tests:
1. Log-based Testing
You can add logs for each operation in the different services, then, you can fetch the logs from those services and validate that the relevant data exists.
There are a few challenges with this approach:
example, there are no written payloads of a request to the logs, they
can’t be validated.
sounds like a perfect way to create flaky tests.
the logs of the operation and not the operation itself. As a result,
we don’t know if the operation succeeded.
2. DB Querying
By saving the operation indication in DB, the DB can be queried during the test to validate if it exists.
There are a few issues with this approach:
And again, just like with the previous log solution, you are testing the DB object update operation and not the actual operation, which is entirely wrong and can’t detect any real issues.
3. Trace-based testing
Instead of over-engineering your applications to make them testable, I suggest a new paradigm that popedup in the indusdrty that doesn’t require any engineering to your code. This way is built upon traces.
Traces are an aggregation of all the operations. Operation in a trace called Span and it's represent any communication between components.
With searchable trace, you can search and validate all kind of spans
. This makes it easy to approach each operation and see it as part of a whole, and not as an individual action.
In addition, traces can be created automatically, without a developer having to decide where to insert them, unlike logs.
You can read more about trace base testing here