[java] 為什麼要使用Hamcrest-Matcher和assertThat()而不是傳統的assertXXX() - 方法



Answers

JUnit版本4.4(引入它)的版本註釋說明了四個優點:

  • 更具可讀性和可鍵入性:這種語法允許您根據主語,動詞,賓語(assert“x is 3”)而不是assertEquals ,它使用動詞,賓語,主語(斷言“等於3 x”)
  • 組合:任何匹配器語句都可以被否定( ),合併( 或者)或者() ),映射到集合( 每個 ),或者在自定義組合中使用( afterFiveSeconds(s)
  • 可讀的故障信息。 (......)
  • 自定義匹配器。 通過自己實現Matcher接口,您可以獲得您自己的自定義斷言的所有上述優點。

來自創建新語法的人的更詳細的論證: here

Question

當我查看Assert類JavaDoc中的示例時

assertThat("Help! Integers don't work", 0, is(1)); // fails:
// failure message:
// Help! Integers don't work
// expected: is <1> 
// got value: <0>
assertThat("Zero is one", 0, is(not(1))) // passes

我沒有看到一個很大的優勢,比方說assertEquals( 0, 1 )

如果結構變得更加複雜但是你看到更多的優勢,那麼也許對於這些消息來說很好? 可讀性?




一個非常基本的理由是很難搞亂新的語法。

假設某個特定值foo在測試後應該為1。

assertEqual(1, foo);

- 要么 -

assertThat(foo, is(1));

採用第一種方法時,很容易忘記正確的順序,並將其向後鍵入。 然後,而不是說測試失敗,因為它預期1並得到2,這個消息是倒退的。 測試通過時不成問題,但當測試失敗時可能導致混淆。

在第二個版本中,犯這個錯誤幾乎是不可能的。




assertThat(frodo.getName()).isEqualTo("Frodo");

接近自然語言。

更容易閱讀,更容易分析代碼。 Programer花更多時間分析代碼,而不是編寫新代碼。 因此,如果代碼易於分析,那麼開發人員應該更高效。

PS代碼應該是寫得很好的書。 自我記錄的代碼。




Links