本文主要是介绍Debezium发布历史132，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
原文地址： https://debezium.io/blog/2022/10/20/flaky-tests/
欢迎关注留言，我是收集整理小能手，工具翻译，仅供参考，笔芯笔芯.
Debugging flaky tests
October 20, 2022 by Vojtěch Juránek
community tests
在为您的项目开发测试时,您可能迟早会遇到一些测试随机失败的情况。这些测试,也被称为剥落测试,非常不愉快,因为您永远不知道失败是随机的还是代码中有回归。最坏的情况是,你忽略了这些测试,因为你知道它们是古怪的。大多数测试框架甚至有一个专用的注释或其他方法来表示测试是不稳定的,如果失败,应该忽略失败。这种测试的价值非常值得怀疑。在这样的测试中,你能做的最好的事情当然是修复它,这样它就不会随机地失败。这很容易说,但很难做到。最困难的部分通常是在您的开发环境中使测试失败,这样您就可以调试它并理解它为什么失败,以及失败的根本原因是什么。在这篇博文中,我将尝试展示一些技术,这些技术可以帮助你模拟本地机器上的随机测试失败。
根据我的经验,随机测试失败的最常见原因是环境不清洁或环境缓慢。这两种情况在CI环境中很常见。过去,由于干扰其他测试而导致的故障更为普遍。如今,当使用虚拟机和容器相当普遍时,这通常不是一个问题。此外,各种CI作为服务提供实现的测试隔离也做得很好。使用CI作为服务的缺点是,通常无法登录机器并调试测试。因此,您必须启用调试日志,等待下一次故障,或者猜测原因,并尝试在本地机器上模拟它。
在CI环境中,随机失败的最常见的根源是各种各样的缓慢。这是虚拟环境中的资源或VMS/容器上设置的资源限制过多的结果。因此,在本地模拟随机测试失败的最有效方法之一是限制在本地环境上的测试资源。让我们看看有什么共同的选择,以及如何去做。
在一个线程中运行测试
减缓测试速度的一个可能方法是在单个线程或有限数量的线程上执行测试,特别是在拥有多线程应用程序时。在Linux操作系统上,使用taskset 指挥官。 任务集 告诉Linux调度器将给定的流程附加到指定的CPU核心。跑例如。德贝兹米斯克 TransactionMetadataIT 在一个CPU核心上,你只需要运行
taskset -c 0 mvn verify -DskipTests -Dit.test=DebeziumEngineIT
在CPU#0上执行测试。
限制集装箱资源
在Debezum项目中,我们大量使用容器进行测试。我们根据容器中运行的测试运行数据库。我们通常需要的不是减缓测试本身,而是减缓数据库。码头提供了很多 选择权 如何限制容器资源。最有用的通常是限制CPU的使用–cpus 参数。这使我们可以限制运行容器时可使用的CPU码头数量。这里的优点是它可以是一个浮号,所以你可以。通过设置限制容器只使用一半CPU时间–cpus=0.5 .同样,你也可以限制其他资源,比如。公羊。
通常的德贝佐姆工作流是从MAVIN运行容器,使用 多克尔梅文插件 .该插件提供了 物业清单长 您可以配置它,包括限制容器资源的属性。然而,这一选择有一个警告。以现在的版本,docker.cpus 期待 长号 而不是浮动和有一个意义,粗略地说,多少CPU纳米秒从一秒钟的循环,容器可以采取。例如。相当于–cpus=0.5 会是:
mvn docker:start -Ddocker.cpus=500000000
这个问题是 固定的 最近和应该在下一个码头的马文插件版本,所以一旦德贝佐姆升级到下一个版本,你应该可以使用docker.cpus 与您在从命令行运行容器时使用的相同方式。其他码头工人的马文插件属性,如。docker.memory 会像预期的那样工作。
引入网络延迟
随机测试失败的另一个常见来源是网络延迟。可能没有任何简单的方法可以在本地机器上模拟它,而且必须使用某种代理。很幸运,有一个代理人正是为了这个目的- 氧化代理 .它是一个专用的代理来模拟各种网络故障和延迟。它有丰富的功能集,而且设置起来很容易,所以很高兴能与它一起工作。让我们看看如何在本地机器上设置Debez测试。
您可以在本地安装toxi代理(在Fedura上通过运行sudo dnf install toxiproxy )或在容器内下载:
docker pull ghcr.io/shopify/toxiproxy
我们将在容器中运行Texi代理,但是在本地安装它也很方便,因为它包含向毒性代理发送命令的CLI实用程序。否则,我们将不得不从容器中运行命令。为了简单起见,我们将使用本地安装的CLI工具。我们可以通过TP发送命令,并在端口8474上监听。因此,当我们启动毒性代理时,我们需要暴露这个端口。我们需要公开的另一个端口是一个数据库的端口,在这个端口中,toxi代理将作为代理。在我们的示例中,我们将使用mysql,因此我们需要公开端口3306。当然,我们可以使用任何其他端口,但是在这种情况下,我们需要传递额外的参数来进行Debezum测试,即database.port 指向被托氏代理暴露的端口。同样,为了简单起见,让我们继续使用默认端口3306。此外,由于我们将从本地机器(而不是容器)运行Debezum测试,我们需要将XXIX代理附加到本地主机网络,该网络默认名称为host .把所有的东西放在一起,我们可以运行如下的代理容器:
docker run --rm -p 8474:8474 -p 3306:3306 --net=host -it ghcr.io/shopify/toxiproxy
现在我们还得启动数据库。由于3306端口已被托克斯代理人占用,我们不得不选择另一个端口,比如3307:
mvn docker:start -Dmysql.port=3307
最后一个缺失的部分是告诉他应该为哪个端口创建代理。在我们的案例中,它来自端口3306(听端口-l )至3307(上游港口-u ):
toxiproxy-cli create mysql -l 0.0.0.0:3306 -u 0.0.0.0:3307
此命令在托西代理中创建一个新的代理,称为mysql .可能有多个代理。我们可以通过
toxiproxy-cli list
就像这样的输出:
$托克斯普洛斯-CLI列表
听上游有毒物质
mysql [::]:3306 0.0.0.0:3307 enabled None
现在我们试着测试一下一切是否正常:
mvn verify -DskipTests -Ddatabase.hostname=localhost -Pskip-integration-tests -Dit.test=TransactionMetadataIT
一切都应该正常运行,因为我们还没有产生任何有毒物质(延迟或失败)。这只是一个检查代理是否正确。如果一切都成功了,我们现在就制造一种有毒的东西:
toxiproxy-cli toxic add mysql --type latency --attribute latency=500 -n mysql_latency
这将在mysql代理上增加500MS的网络延迟。毒性被命名为"Mysql_延迟"。
您可以通过运行来获得关于指定代理的更多细节inspect 指挥:
toxiproxy-cli inspect mysql
像这样的输出:
$托克斯普洛斯-cli检查mysql
Name: mysql Listen: [::]:3306 Upstream: 0.0.0.0:3307
上游有毒物质:
代理人没有上游的有毒物质。
下游有毒物质:
Mysql_延迟:类型=延迟流=下游毒性=1.00属性=[颤抖=0延迟=500]
再做一次测试。你注意到测试时间长了吗?如果是的,所有的工作都如预期的那样,因为我们为数据库的每个调用添加了延迟。
这是一个向氧化代理添加有毒的简单例子。托西代理提供了许多配置有毒物质的选择和方法。看 氧化代理 更多的细节。
一旦做完,我们就可以移除有毒的
toxiproxy-cli toxic remove mysql -n mysql_latency
以及代理人本身:
toxiproxy-cli delete mysql
或者简单地停止并删除容器。
概括的
在这篇博文中,我试图展示一些技术,这些技术可以帮助您在本地模拟一些不稳定的测试失败。所有的测试都试图降低测试环境的响应性,即通过限制CPU或使用托奇代理来增加网络延迟。在应用程序堆栈的许多部分,测试可能会变得不可靠还有很多其他原因,还有很多其他的工具可以注入各种各样的失败(例如)。磁盘故障)。所以这篇文章还不够详尽。但我希望它能帮助您调试至少一些剥落的测试,如果不是在Debezum项目,那么至少是在您自己的项目中。
所有这些东西,特别是一切都可以定期使用,即使在CI中,也可以用来发现项目中的各种隐藏问题,而这些问题只有在它运行的环境中表现不佳时才会出现。
你可以在讨论中分享任何其他关于如何调试破片测试的提示,以及你能找到什么样的工具。
这篇关于Debezium发布历史132的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
