2010-06-03 185 views
61

今天我看到了一個JUnit測試用例,其中包含一個java斷言而不是JUnit斷言 - 是否存在比另一個更重要的優點或缺點?斷言與JUnit斷言

+4

我認爲這個問題應該重新打開:最好的答案是非常有用的。 – jakebeal 2017-02-17 22:21:42

+0

JUnit斷言與Java'assert'關鍵字之間絕對有實際差異。這完全不是一個基於意見的問題。 – 2018-01-10 23:59:02

回答

78

在JUnit4通過一個JUnit斷言拋出的異常(實際上是錯誤)是一樣的由Java assert關鍵字(Asse田)拋出的錯誤,所以它是完全比:我喜歡堆棧跟蹤一樣assertTrue等說出不同之處。

這就是說,assert必須在JVM中運行一個特殊的標誌,導致很多測試似乎只是因爲有人忘了在JUnit測試運行時忘記使用該標誌來配置系統 - 這並不好。因此,我認爲使用JUnit assertTrue是更好的做法,因爲它確保測試運行,確保一致性(您有時使用assertThat或其他不是java關鍵字的斷言),並且如果JUnit斷言的行爲應該在將來發生變化(例如掛鉤某種過濾器或其他未來的JUnit功能),那麼代碼將能夠利用該功能。

java中assert關鍵字的真正目的是能夠關閉它,而不會造成運行時損失。這不適用於單元測試。

24

我喜歡JUnit斷言,因爲它們提供比更豐富的API內置assert聲明,更重要的不需要不像assert,這就需要-ea JVM參數明確啓用。

+0

'-ea'總是在'mvn test'中啓用,不需要'-ea'。更豐富的API,很好的捕獲。有時我認爲API在測試中被濫用,因爲它不是應用程序的一部分(api中),我寧願將它稱爲更豐富的方法。 – 2018-01-11 03:23:46

0

我會說,如果你使用JUnit,你應該使用JUnit斷言。 assertTrue()assert基本相同,否則爲什麼要使用JUnit?

+2

您將使用JUnit作爲測試運行框架。斷言實際上是JUnit給你的價值的一小部分。沒有'Assert'的JUnit需要更多的樣板。沒有JUnit的'assert'會要求你編寫一個完整的框架。 – Yishai 2010-06-03 13:41:34

+0

我更多地說如果你要使用這個工具,使用工具。在JUnit測試用例中,常規的舊聲明陳述看起來有點愚蠢。在我看來,他們屬於實際的代碼。 – CheesePls 2010-06-03 14:01:13

+0

@CheesePls「常規舊斷言」實際上比JUnit斷言更新。 – dolmen 2012-08-09 09:55:20

0

這可能不適用,如果你專門使用那些有光澤和新的東西,但斷言在1.4SE之前沒有被引入Java。因此,如果您必須在具有較舊技術的環境中工作,則出於兼容性原因,您可能會傾向於JUnit。

11

當測試失敗時,您將獲得更多信息。

assertEquals(1, 2);結果java.lang.AssertionError: expected:<1> but was:<2>

VS

assert(1 == 2);結果java.lang.AssertionError

,如果你添加的消息參數assertEquals

+2

嘗試'斷言1 == 2:「1不是2」;'。 – 2015-12-08 10:03:10

+0

@PeterRader當-ea未啓用時,嘗試assert關鍵字。或者更好的是,使用總是有效的JUnit斷言。 – 2018-01-10 23:57:21

+0

@ThomasW當-ea未啓用時,它不是測試。如果您決定使用JUnit什麼是框架,並且在maven是Maven依賴項的情況下,它只能在測試範圍內使用Maven依賴項,所以它們只能在JUnit中正常工作。我們在這裏有兩個方面:你喜歡什麼? **第一面**:只使用框架作爲測試範圍中的依賴項,必須下載,eclipse允許您在不在src/main-folder中的類中使用,但不會在那裏編譯,因爲maven有junit只在測試範圍或**第二方**:使用內置的東西。 – 2018-01-11 03:18:45

5

我會說使用JUnit斷言,你可以得到更多的信息在測試用例中,並在代碼中使用java的斷言。換句話說,真正的代碼永遠不會有JUnit的依賴關係,如果它是一個測試,它應該使用它的JUnit變體,而不是斷言。