为什么 assertEquals 中的可选断言消息移动到 Junit 5 中的最后一个位置？

我将尝试澄清我们在3年前设计JUnit 5 API（现在体现在Jupiter测试引擎中）时的思维过程。当时在场的其他人（马克·菲利普、山姆·布兰宁、马蒂亚斯·默德斯和斯特凡·贝希托尔德）可能会插话并纠正我的记忆......

我们有一些基本的约束：

1. 从编译器的角度来看，JUnit 5 API应该与旧版本完全分开，以便来自不同版本的测试可以并排进行。

2. 尽管如此，API应该感觉很熟悉，以便轻松迁移

3. API应该包含Java API设计的最新技术和良好实践

确定 中所有断言方法的可选消息参数始终是最后一个，这是第 2 点和第 3 点之间的权衡。这更有意义，因为我们允许争论。在断言语句的第一个位置使用 lambda 表达式看起来很奇怪且会分散注意力 - 所以我们这么想。org.junit.jupiter.api.AssertionsSupplier<String> messageSupplier

事后看来，我可能会主张对断言API进行更彻底的改变，以放弃这个问题中触及的那种混乱。我甚至会推动不要使用作为测试方法的主要标记，考虑到JUnit Jupiter新来者导入旧注释的频率，并想知道为什么系统表现得很奇怪。@Testorg.junit.Test

这需要询问作者自己，但这是其他库的常见模式。

例如，番石榴，甚至是JDK本身。该可选参数成为“最后一个”IMO是有道理的（但这当然是基于意见的）。Preconditions#checkNotNullObjects#requireNoNull