2017-05-03 62 views
4

assert!(a == b)assert_eq!(a, b)佔用更少的字符,在我看來,它更具可讀性。爲什麼`assert_eq`和`assert_ne`存在一個簡單的`assert`就足夠了?

錯誤消息是或多或少是相同的:

thread 'main' panicked at 'assertion failed: `(left == right)` (left: `1`, right: `2`)', src\main.rs:41 

thread 'main' panicked at 'assertion failed: 1 == 2', src\main.rs:41 

實際上,這個問題不僅是鏽病;我總是看到在單元測試框架這些不同的斷言宏或功能:

  • Cpputest有CHECKCHECK_FALSECHECK_EQUAL等;
  • Googletest有EXPECT_GTEXPECT_EQ等等;
  • JUnit有assertEqualsassertFalse,並繼續。

通常還有一些特定類型的字符串或數組聲明。重點是什麼?

回答

7

線程「主」在恐慌「斷言失敗:1 == 2」,

你舉的例子是看到有在使用assert_eq!一個很大的優勢太簡單了。考慮以下代碼:

let s = "Hello".to_string(); 
assert!(&s == "Bye"); 

這是造成恐慌的消息:

'assertion failed: &s == "Bye"'  

現在,讓我們看看當我們使用會發生什麼assert_eq!

let s = "Hello".to_string(); 
assert_eq!(&s, "Bye"); 

消息:

'assertion failed: `(left == right)` (left: `"Hello"`, right: `"Bye"`)' 

此消息pro比前者更具洞察力。其他單元測試系統通常也是這樣。

+2

對。你的測試框架應該可以幫助你。簡單地說「一個測試失敗」比說「由於這些原因測試失敗*」沒有多大幫助。還有我們爲什麼要首先創建名稱的函數的全部方面 - 具有可讀性和可理解的代碼。 – Shepmaster

+0

@Shepmaster我不確定assert_eq本身更具可讀性,但更多的信息性錯誤信息當然更好。 – Amomum

+1

@Amomum:實際上有一個改進assert_eq的RFC,同時你可能對[pretty_assertions](https://crates.io/crates/pretty_assertions)箱子感興趣。 –

相關問題