对于测试来说，编写断言似乎很简单：我们只需要对结果和预期进行比较，通常使用断言方法进行判断，例如测试框架提供的assertTrue()或者assertEquals()方法。然而，对于更复杂的测试场景，使用这些基础的断言验证结果可能会显得相当笨拙。
　　使用这些基础断言的主要问题是，底层细节掩盖了测试本身，这是我们不希望看到的。在我看来，应该争取让这些测试使用业务语言来说话。
　　在本篇文章中，我将展示如何使用“匹配器类库”（matcher library）;来实现自定义断言，从而提高测试代码的可读性和可维护性。
　　为了方便演示，我们假设有这样一个任务：让我们想象一下，我们需要为应用系统的报表模块开发一个类，输入两个日期（开始日期和结束日期），这个类将给出这两个日期之间所有的每小时间隔。然后使用这些间隔从数据库查询所需数据，并以直观的图表方式展现给终用户。
　　标准方法
　　我们先采用“标准”的方法来编写断言。我们以JUnit为例，当然你也可以使用TestNG。我们将使用像assertTrue()、assertNotNull()或assertSame()这样的断言方法。
　　下面展示了HourRangeTest类的其中一个测试方法。它非常简单。首先调用getRanges()方法，得到两个日期之间所有的每小时范围。然后验证返回的范围是否正确。

 

private final static SimpleDateFormat SDF
= new SimpleDateFormat("yyyy-MM-dd HH:mm");
@Test
public void shouldReturnHourlyRanges() throws ParseException {
// given
Date dateFrom = SDF.parse("2012-07-23 12:00");
Date dateTo = SDF.parse("2012-07-23 15:00");
// when
final List<range> ranges = HourlyRange.getRanges(dateFrom， dateTo);
// then
assertEquals(3， ranges.size());
assertEquals(SDF.parse("2012-07-23 12:00").getTime()， ranges.get(0).getStart());
assertEquals(SDF.parse("2012-07-23 13:00").getTime()， ranges.get(0).getEnd());
assertEquals(SDF.parse("2012-07-23 13:00").getTime()， ranges.get(1).getStart());
assertEquals(SDF.parse("2012-07-23 14:00").getTime()， ranges.get(1).getEnd());
assertEquals(SDF.parse("2012-07-23 14:00").getTime()， ranges.get(2).getStart());
assertEquals(SDF.parse("2012-07-23 15:00").getTime()， ranges.get(2).getEnd());
}

　　毫无疑问这是个有效的测试。然而，它有个严重的缺点。在//then后面有大量的重复代码。显然，它们是复制和粘贴的代码，经验告诉我，它们将不可避免地会产生错误。此外，如果我们写更多类似的测试（我们肯定还要写更多的测试来验证HourlyRange类），同样的断言声明将在每一个测试中不断地重复。
　　过多的断言和每个断言的复杂性减弱了当前测试的可读性。大量的底层噪音使我们无法快速准确地了解这些测试的核心场景。我们都知道，阅读代码的次数远大于编写的次数（我认为这同样适用于测试代码），所以我们理所当然地要想办法提高其可读性。
　　在我们重写这些测试之前，我还想重点说一下它的另一个缺点，这与错误信息有关。例如，如果getRanges()方法返回的其中一个Range与预期不同，我们将得到类似这样的信息：
　　org.junit.ComparisonFailure:
　　Expected :1343044800000
　　Actual :1343041200000
　　这些信息太不清晰，理应得到改善。