在微服务环境中测试异步通信

发布于 2025-02-12 02:49:03 字数 105 浏览 1 评论 0原文

我有一个用于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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

甜中书 2025-02-19 02:49:03

这是一个真正的痛苦。异步通信使测试微服务环境更加困难,无法访问状态代码和例外。这样的应用程序的“层”使创建测试变得更加困难。

如果要创建测试,则有一些选择:

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:

  • You assume that the developer added logs for the operation you want to validate, which is not always true.
  • You can only validate the data that was written in the logs. If, for
    example, there are no written payloads of a request to the logs, they
    can’t be validated.
  • You are coupling logs and the tests – which
    sounds like a perfect way to create flaky tests.
  • You are testing only
    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:

  • You need to expose the database to the tests project, which sometimes requires heavy lifting.
  • You need to engineer the database for the tests, which is overengineering and not the focus of our work, making it a weird thing to do.
  • You coupled our DB model to the tests, which is logically wrong.
    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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文