信任断言库与AssertJ的比较
我使用fest-assert，并在它停止开发后移到assertJ。
最近，我被指向Google repository和另一个断言库truth(http://Google.github.io/truth/）。
阅读这些示例，我没有发现使用start比使用assertJ有任何优势。所以用什么只是品味的问题。但也许我没抓住重点，是吗？
共有1个答案
来自他们在GitHub的一条评论：
核心的区别在于，真值的设计包括两个具体的可扩展性领域--命题失败的策略--这样，整数的“主语”或字符串的主语可以在完全不同的失败结果的上下文中重用。一个值得注意的例子是JUnit使用AssertionError和它使用AssemptionViolationException之间的区别。Truth允许对这两个类使用相同的命题类。
灵活性的另一个方面是能够创建新的断言/命题类型并将它们挂钩，而无需声明可能冲突的静态方法来导入。这可以用于新类型（例如，添加protobufs)，也可以用于现有类型的新用途（例如，将字符串视为URI）。这是assertAbout（）特性。
除此之外，Truth与AssertJ非常相似，因为它的灵感来自FEST，而AssertJ是2.0开发线的一个分支。
总而言之，Truth被设计成更具可扩展性和灵活性，但是AssertJ对于标准类型的断言将是很棒的（可能是最棒的）。
-
...我需要使用AssertJ将实际对象与预期对象进行比较。但是，、和字段具有动态值，我无法将其硬编码到断言中。 因此以下断言将失败: 然后，我发现以下内容将忽略某些字段： null 或者除了为每个字段编写一个断言之外没有其他方法吗？
-
这当然不能编译。 导致该问题的示例代码如下： null 但是T在上下文中是不知道的。 这并没有什么不同。 有没有我错过的解决方案？
-
基本上，问题是是否有AssertJ（首选）或JUnit断言： 我的测试类(CUT)扩展了JAXB的。解组XML文件时，它应该保证相等的对象恰好存在一次。为了验证这一点，我的测试当前看起来是这样的（在示例中，标准ctor创建相等对象）：
-
使用Hamcrest可以很容易地否定匹配器。例如。您可以这样编写断言：
-
问题内容： 今天，我看到了一个带有Java断言而不是JUnit断言的JUnit测试用例-相对于另一个而言，优先选择一个优点还是缺点？ 问题答案： 在JUnit4中，JUnit断言引发的异常（实际上是Error）与java 关键字（AssertionError）引发的错误相同，因此它与堆栈跟踪完全相同，除了您无法分辨出其区别。 话虽这么说，断言必须在JVM中使用特殊标志运行，导致许多测试似乎通过了，
-
我正在阅读使用Assertj验证结果的测试类。偶尔，我会发现一个没有断言的断言。 是否有可能在开发周期的某个地方识别这些类？我的第一个猜测是使用自定义声纳规则。虽然我不明白应该如何定义这个方法后面应该跟一个断言（返回void的方法？）。