断言与 JUnit 断言
今天我看到一个使用 java 断言而不是 JUnit 断言的 JUnit 测试用例——偏爱一个比另一个有明显的优点或缺点吗？
在 JUnit4 中，JUnit 断言抛出的异常（实际上是错误）与 java assert 关键字（AssertionError）抛出的错误相同，因此它与 assertTrue 完全相同，但堆栈跟踪除外。 t 区分。
话虽如此，断言必须在 JVM 中使用特殊标志运行，这导致许多测试似乎通过，因为有人在运行 JUnit 测试时忘记使用该标志配置系统 - 不好。
一般来说，正因为如此，我认为使用 JUnit assertTrue 是更好的做法，因为它保证测试运行，确保一致性（您有时使用 assertThat 或其他不是 java 关键字的断言）和如果 JUnit 断言的行为将来会发生变化（例如挂钩某种过滤器或其他未来的 JUnit 功能），您的代码将能够利用它。
在 java 中 assert 关键字的真正目的是能够在没有运行时损失的情况下将其关闭。这不适用于单元测试。
我更喜欢 JUnit 断言，因为它们提供了比内置 assert 语句更丰富的 API，更重要的是不需要显式启用，这与需要 -ea JVM 参数的 assert 不同。
当测试失败时，您将获得更多信息。
assertEquals(1, 2); 结果为 java.lang.AssertionError: expected:<1> but was:<2>
对比
assert(1 == 2); 结果为 java.lang.AssertionError
如果您将消息参数添加到 assertEquals，您可以获得更多信息
assert 1==2: "1 is not 2";。
assert —— 用于会影响性能的正确性检查，因此最好默认禁用。然而，我的经验是，大多数断言应该永远在线。
我会说在测试用例中使用 JUnit 断言，并在代码中使用 java 的断言。换句话说，真正的代码永远不应该有 JUnit 依赖，很明显，如果它是一个测试，它应该使用它的 JUnit 变体，而不是断言。
我会说如果你使用 JUnit，你应该使用 JUnit 断言。 assertTrue() 与 assert 基本相同，否则为什么还要使用 JUnit？
Assert 的 JUnit 需要更多样板文件。 assert 如果没有 JUnit，您将需要编写一个完整的框架。
如果您专门使用闪亮和新的东西，这可能不适用，但直到 1.4SE 才将断言引入 Java。因此，如果您必须在使用旧技术的环境中工作，出于兼容性原因，您可能会倾向于使用 JUnit。
-ea始终在mvn test中启用，不需要-ea。更丰富的api，很好的捕获。有时我认为 API 在测试中被误用，因为它不是应用程序的一部分（API 中的一个），我更喜欢称它为更丰富的方法。