JUnit是由 Erich Gamma 和 Kent Beck 編寫的一個回歸測試框架（regression testing framework）。Junit測試是程序員測試，即白盒測試。該項目主頁：http://www.junit.org/
使用JUnit時，主要都是通過繼承TestCase類別來撰寫測試用例，使用testXXX()名稱來撰寫單元測試。
用JUnit寫測試真正所需要的就三件事：
1． 一個import語句引入所有junit.framework.*下的類。
2． 一個extends語句讓你的類從TestCase繼承。
3． 一個調用super(string)的構造函數。
功能類MathTool
package com.zj.c01;public class MathTool { public static int gcd(int num1, int num2) { int r = 0; while (num2 != 0) { r = num1 % num2; num1 = num2; num2 = r; } return num1; } } 測試類MathToolTest
package com.zj.c01;import junit.framework.TestCase; public class MathToolTest extends TestCase { public MathToolTest(String name) { super(name); } public void testGcd() { assertEquals(5, MathTool.gcd(10, 5)); } } 我們在用 JUnit 測試方法異常的時候，最容易想到的辦法就是用 try…catch 去捕獲異常，需要斷言以下幾個條件：
1. 確實拋出的異常
2. 拋出異常的 Class 類型
3. 拋出異常的具體類型，一般檢查異常的 message 屬性中包含的字符串的斷定
所以常用的代碼你可能會這么寫：
@Test public void testBizException(){ try{ Password.validate( "123" ); fail( "No exception thrown." ); }catch ( Exception ex ) { assertTrue( ex instanceof BizException ); assertTrue( ex.getMessage().contains( "error" ) ); } } 這里被測試的方法是 Password.validate() 方法是否拋出了相應的異常，注意這里別漏 try 中的
fail(“No Exception thrown.”)
代碼行，不然如果被測試的方法如果沒有拋出異常的話，這個用例是通過的，而你預期的是要拋出異常的。
在 JUnit 4 中，大可不必如此這般的去測試方法異常。雖然這樣也能測定出是否執行出預期的異常來，但它仍有弊端，接下來會一對比就知道了，try…catch 的方法，JUnit 無法為你提示出詳細的斷言失敗原因。
那么來看看自從 JUnit 4 后可以怎么去測試異常呢?用 @Test(execpted=Exception.class) 注解就行，參考如下代碼：
@Test( expected = BizException.class ) public void testBizException(){ Password.validate( null ); }
如果被測試的方法有拋出 BizException類型便是斷言成功，對了 @Test(expected = BizException.class) 只能判斷出異常的類型，并無相應的注解能斷言出異常的更具體的信息，即無法判定拋出異常的 message 屬性。
那么，有時候我們會在一個方法中多次拋出一種類型的異常，但原因不同，即異常的 message 信息不同，比如出現 BizException 時會有以下兩種異常：
new BizException(“Password must contains at least 6 letters.”) new BizException(“Password length less than 15 letters”)
這就要有辦法去斷言異常的 message 了，針對于此，自 JUnit 4.7 之后又給了我們更完美的選擇，就是下面的代碼：
@Rule public ExpectedException expectedEx = ExpectedException.none(); @Test public void testBizException() throws InvalidPasswordException{ expectedEx.expect( BizException.class ); expectedEx.expectMessage( "required" ); Password.validate( "" ); } 上面代碼需重點關注幾個：
1. @Rule 注解的 ExpectedException 變量聲明，它必須為 public
2. @Test 處，不能寫成 @Test(expected=BizException.class)，否則不能正確測試，也就是
@Test(expected=BizException.class) 和測試方法中的 expectedEx.expectXxx() 方法是不能同時并存的
3. expectedEx.expectMessage() 中的參數是 Matcher 或 subString，就是說可用正則表達式判定，或判斷是否包含某個子字符串
4. 再就是有一點很重，把被測試方法寫在 expectedEx.expectXxx() 方法后面，不然也不能正確測試的異常
5. 最后一個是，只要測試方法直接拋出被測試方法的異常即可，并不影響你所關心的異常
前面說到用 try…catch 的辦法也能正確測試到異常，@Test(expected=…) 或 @Rule 與 try…catch 的方法對比有什么好處呢，顯然用 JUnit 4 推薦的方法簡潔明了。再來看測試失敗時 JUnit 會為你提示什么呢?
try…catch 測試異常失敗時，得到的提示:
無異常時：
java.lang.AssertionError: No exception thrown. at org.junit.Assert.fail(Assert.java:91) at cc.unmi.PasswordTest.passwordLengthLessThan6LettersThrowsException(PasswordTest.java:20)
異常類型不對或異常的 message 不對時：
java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at cc.unmi.PasswordTest.passwordLengthLessThan6LettersThrowsException(PasswordTest.java:22)
上面能提供給我們的定位錯誤的幫助不是特別大
再看 @Test(expected=BizException.class) 時測試失敗時的提示：
java.lang.AssertionError: Expected exception: cc.test.BizException at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
用 @Rules ExpectedException方式來測試異常，失敗時的提示：
java.lang.AssertionError: Expected: (exception with message a string containing “YES. required” and an instance of java.lang.NullPointerException) got: at org.junit.Assert.assertThat(Assert.java:778) at org.junit.Assert.assertThat(Assert.java:736) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:114)
特別是 @Rules ExpectedException 方法時為何測試失敗提示的清清楚楚。期望什么異常，異常 message 中含何字符串，實際上確得到什么類型的異常，異常中 message 是什么。有了這，你一看到就知道怎么去修補你的程序。
新聞熱點
疑難解答
