对于测试来说，编写断言似乎很简单：我们只需要对结果和预期进行比较，通常使用断言方法进行判断，例如测试框架提供的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
这些信息太不清晰，理应得到改善。
