小菜一碟！最好保持到一行，你要进行测试的独立操作。有时候，你专门测试的是输出是什么，如果某些东西被多次调用，或者在某些优先操作之后调用的结果是什么，所以这不是一个硬性规定。当读取测试时，用户应该快速而轻松地能说“将这些值设置成这样，如果我执行这个操作/这些操作，那么这是预期的结果”。在上面的例子中，便是 bookstore.findByTitle ()方法。
断言
使用 Hamcrest。 Hamcrest 是一个很棒的库，给我们一个流畅的 API 用来写入测试。不会像这样的代码：
assertEquals (results.size (), 2); assertTrue (results.contains (aHarryPotterBook)) assertTrue (results.contains (anotherHarryPotterBook))
我们可以一目了然、轻松地阅读像这样的代码：
assertThat (results.size (), is(2)); assertThat (results, containsInAnyOrder (aHarryPotterBook, anotherHarryPotterBook));
这些相当简单的例子：Hamcrest 有很多伟大的方法，使编写复杂测试变得很容易，并允许你创建自己的匹配器。
当然，理想情况下，我们希望有一个独立的断言。这可以让我们知道我们正在测试什么，并说明我们的代码没有意外情况。就像这篇文章中所说的那样，这不是一个硬性的规则，因为在某些情况下，这是必要的，但如果你有这样一个的测试：
assertThat (orderBook.bids.size (), is(4)); assertThat (orderBook.asks.size (), is(3)); assertThat (orderBook.bids.get(0) .price, is(5200)); assertThat (orderBook.asks.get(2) .price, is(10000000)); assertThat (orderBook.asks.get(2) .isBuy, is(false));
那么要理解测试哪里失败或哪条断言重要就变得困难多了。
你也可以在 Hamcrest 中编写自定义的匹配器，因为 Hamcrest 可为复杂断言提供一个优雅的解决方案。如果你需要在一个循环中运行断言，或者你有大量的字段要断言，那么一个自定义的匹配器可能才是上上之选。
一个测试的最重要的部分之一是，当它失败时，哪怕是一个 5 岁孩子也应该看得出什么地方出了错以及哪里错了。失败的消息一定不能含糊。关于这方面的解决方法是：
如果做任何类型的对象比较，那么保证对象有一个体面的 toString（）消息。没有什么比<MyObject @ 142131>不匹配更糟的了。
想要做的更好的话，可以对你的对象使用自定义匹配器。你可以准确地知道哪些字段未能匹配。
确保明确为什么你要选择和这个值作比较。例如，如果你正在将一个字段值与数字 3000 比较，那么为什么是 3000？你应该费力地明白这一点。显然，这个数字不是随便得来的，并且还要确保该变量的命名可以显示它的值是如何得来的。
所有这些都应该是在一个适度的常识范围内。没有严格规定！
你还有什么要补充的吗？欢迎告诉我们。