自定義斷言
擁有AssertJ或者Hamcrest提供的更強大的斷言集合的確很好，但對于HourRange類來說，這并不是我們真正想要的。匹配器類庫的另一個功能是允許你編寫自己的斷言。這些自定義斷言的行為將與AssertJ的默認斷言一樣，也就是說，你能夠把它們串在一起。這正是我們接下來要做的。
接下來我們將看到一個自定義斷言的示例實現，但現在讓我們先看看最終效果。這次我們將使用（我們自己的）RangeAssert類的assertThat()方法。
@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 List<Range> ranges = HourlyRange.getRanges(dateFrom, dateTo); // then RangeAssert.assertThat(ranges) .hasSize(3) .isSortedAscending() .hasRange("2012-07-23 12:00", "2012-07-23 13:00") .hasRange("2012-07-23 13:00", "2012-07-23 14:00") .hasRange("2012-07-23 14:00", "2012-07-23 15:00"); } |
即便是上面這么小的一個例子，我們也能看出自定義斷言的一些優勢。首先要注意的是//then后面的代碼確實變少了，可讀性也更好了。
將自定義斷言應用于更大的代碼庫時，將顯現出其它優勢。當我們繼續使用自定義斷言時，我們將注意到：
可以很容易地復用它們。我們不強迫使用所有斷言，但對特定測試用例，我們可以只選擇那些重要的斷言。
特定領域語言屬于我們，也就是說，對于特定測試場景，我們可以根據自己的喜好改變它（例如，傳入Date對象，而不是字符串）。更重要的是這樣的改變不會影響到其它測試。
高可讀性。毫無疑問，因為斷言包括了很多小斷言方法，每一個都只關注校驗的很小的某個方面，因此可以為校驗方法取一個恰當的名字。
與私有斷言方法相比，自定義斷言的唯一不足是工作量要大一些。我們來看一下自定義斷言的代碼，它是否真的是一個很難的任務。
要創建自定義斷言，我們需要繼承AssertJ的AbstractAssert類或者其子類。如下所示，我們的RangeAssert繼承自AssertJ的ListAssert類。這很正常，因為我們的自定義斷言將校驗一個Range列表（List<Range>）。
每一個使用AssertJ的自定義斷言都會包含創建斷言對象、注入被測對象的代碼，然后可以使用更多的方法對其進行操作。如下面的代碼所示，構造方法和靜態assertThat()方法的參數都是List<Range>。
public class RangeAssert extends ListAssert<Range> {
protected RangeAssert(List<Range> ranges) {
super(ranges);
}
public static RangeAssert assertThat(List<Range> ranges) {
return new RangeAssert(ranges);
}
現在我們看看RangeAssert類的其余內容。hasRange()和isSortedAscending()方法（顯示在下一個代碼列表中）是自定義斷言方法的典型例子。它們具有以下共同點：
它們都先調用isNotNull()方法，檢查被測對象是否為null。確保這個校驗不會失敗并拋出NullPointerException異常消息。（這一步不是必須的，但建議有這一步）
它們都返回“this”（也就是自定義斷言類的對象，對應例子中RangeAssert類的對象）。這使得所有方法可以串在一起。
它們都使用AssertJ Assertions類（屬于AssertJ框架）提供的斷言方法執行校驗。
它們都使用“真實”的對象（由父類ListAssert提供），確保Range列表（List<Range>）被校驗。
private final static SimpleDateFormat SDF = new SimpleDateFormat("yyyy-MM-dd HH:mm"); public RangeAssert isSortedAscending() { isNotNull(); long start = 0; for (int i = 0; i < actual.size(); i++) { Assertions.assertThat(start) .isLessThan(actual.get(i).getStart()); start = actual.get(i).getStart(); } return this; } public RangeAssert hasRange(String from, String to) throws ParseException { isNotNull(); Long dateFrom = SDF.parse(from).getTime(); Long dateTo = SDF.parse(to).getTime(); boolean found = false; for (Range range : actual) { if (range.getStart() == dateFrom && range.getEnd() == dateTo) { found = true; } } Assertions .assertThat(found) .isTrue(); return this; } } |
那么錯誤信息呢？AssertJ讓我們可以很容易地添加錯誤信息。對于簡單的場景，例如值的比較，通常使用as()方法就足夠了，示例如下：
Assertions
.assertThat(actual.size())
.as("number of ranges")
.isEqualTo(expectedSize);
正如你所見到的，as()只是AssertJ框架提供的另一個方法。當測試失敗時，它打印下面的信息，我們立即就能知道哪兒錯了：
org.junit.ComparisonFailure: [number of ranges]
Expected :4
Actual :3
有時候只知道被測對象的名字是不夠的，我們需要更多信息以了解到底發生了什么。以hasRange()方法為例，當測試失敗時，如果能夠打印所有range就更好了。我們可以通過overridingErrorMessage()方法來實現這種效果：
public RangeAssert hasRange(String from, String to) throws ParseException {
...
String errMsg = String.format("ranges\n%s\ndo not contain %s-%s",
actual ,from, to);
...
Assertions.assertThat(found)
.overridingErrorMessage(errMsg)
.isTrue();
...
}
現在，當測試失敗時，我們能夠得到非常詳細的信息。它的內容取決于Range類的toString()方法。例如，它看起來可能是這樣的：
HourlyRange{Mon Jul 23 12:00:00 CEST 2012 to Mon Jul 23 13:00:00 CEST 2012},
HourlyRange{Mon Jul 23 13:00:00 CEST 2012 to Mon Jul 23 14:00:00 CEST 2012},
HourlyRange{Mon Jul 23 14:00:00 CEST 2012 to Mon Jul 23 15:00:00 CEST 2012}]
do not contain 2012-07-23 16:00-2012-07-23 14:00
總結
在本文中，我們討論了很多編寫斷言的方法。我們從“傳統”的方式開始，也就是基于測試框架提供的斷言方法。對于很多場景，這已經非常好了。但是正如我們所看到的，它在表達測試意圖時，有時候缺少了一些靈活性。之后，我們通過引入私有斷言方法，取得了一點改善，但仍然不是理想的解決方案。最后，我們嘗試使用AssertJ編寫自定義斷言，我們的測試代碼取得了非常好的可讀性和可維護性。
如果要我提供一些關于斷言的建議，我將會建議以下內容：如果你停止使用測試框架（例如JUnit或TestNG）提供的斷言，改為使用匹配器類庫（例如AssertJ或者Hamcrest），你的測試代碼將得到極大的改善。你將可以使用大量可讀性很強的斷言，減少測試代碼中//then之后的復雜聲明。
盡管編寫自定義斷言的成本非常低，但也沒有必要因為你會寫就一定要使用它們。當你的測試代碼的可讀性并且/或者可維護性變差時使用它們。根據我的經驗，我會鼓勵你在以下場景中使用自定義斷言：
當你發現使用匹配器類庫提供的斷言無法清晰表達測試意圖時；
作為私有斷言方法的替代方案。
我的經驗告訴我，單元測試幾乎不需要自定義斷言。而在集成測試和端到端測試（功能測試）中，我敢說你肯定會發現它們是不可替代的。它們能讓你的測試用領域語言說話（而不是實現語言），它們還封裝了技術細節，使測試更易于更新。
關于作者
Tomek Kaczanowski是CodeWise公司（克拉科夫，波蘭）的一名Java開發人員。他專注于代碼質量、測試和自動化。他是TDD的狂熱者、開源的倡導者和敏捷的崇拜者。具有強烈的分享知識傾向。書的作者、博客和會議發言人。Twitter: @tkaczanowski