Demo如下：
　　@RunWith(Parameterized.class)
　　public class SquareTest {
　　private static Calculator calculator = new Calculator();
　　private int param;//參數(shù)
　　private int result;//期望值
　　// 準(zhǔn)備數(shù)據(jù) 
　　@Parameters  
　　public static Collection data() {
　　return Arrays.asList(new Object[][]{{2， 4}，{0， 0}，{－3， 9}});
　　}
　　//構(gòu)造函數(shù)，對變量進(jìn)行初始化
　　public SquareTest(int param， int result) {
　　this.param = param;
　　this.result = result;
　　}
　　@Test  
　　public void square() {
　　calculator.square(param);
　　assertEquals(result， calculator.getResult());
　　}
　　}
　　打包測試
　　在一個項(xiàng)目中，只寫一個測試類是不可能的，我們會寫出很多很多個測試類�？墒沁@些測試類必須一個一個的執(zhí)行，也是比較麻煩的事情。鑒于此，JUnit為我們提供了打包測試的功能，將所有需要運(yùn)行的測試類集中起來，一次性的運(yùn)行完畢，大大的方便了我們的測試工作。具體代碼如下：
　　@RunWith(Suite.class)
　　@Suite.SuiteClasses({ CalculatorTest.class，SquareTest.class})
　　public class AllCalculatorTests{
　　}
　　大家可以看到，這個功能也需要使用一個特殊的Runner，因此我們需要向@RunWith注解傳遞一個參數(shù)Suite.class。同時，我們還需要另外一個注解@Suite.SuiteClasses，來表明這個類是一個打包測試類。我們把需要打包的類作為參數(shù)傳遞給該注解可以了。有了這兩個注解之后，已經(jīng)完整的表達(dá)了所有的含義，因此下面的類已經(jīng)無關(guān)緊要，隨便起一個類名，內(nèi)容全部為空既可。
　　異常測試
　　在JUnit 4之前，對錯誤的測試，我們只能通過fail來產(chǎn)生一個錯誤，并在try塊里面assertTrue(true)來測試�，F(xiàn)在，可以通過@Test 注解中的expected屬性來測試異常。expected屬性的值是一個異常的類型。
　　Demo如下：
　　@Test(expected=ArithmeticException.class)
　　public void testDivide() {
　　new Calculator().divide(6， 0);
　　}
　　測試
　　對于那些邏輯很復(fù)雜，循環(huán)嵌套比較深的程序，很有可能出現(xiàn)死循環(huán)，因此一定要采取一些預(yù)防措施。測試是一個很好的解決方案。我們給這些測試方法設(shè)定一個執(zhí)行時間，超過了這個時間，他們會被系統(tǒng)強(qiáng)行終止，并且系統(tǒng)還會向你匯報(bào)該方法結(jié)束的原因是因?yàn)槌瑫r，這樣你可以發(fā)現(xiàn)這些Bug了。要實(shí)現(xiàn)這一功能，只需要給@Test 注解加一個timeout屬性，該注解傳入了一個時間（毫秒）給測試方法，如果測試方法在指定的時間之內(nèi)沒有運(yùn)行完，則測試失敗。
　　Demo如下：  
　　@Test(timeout=1000)
　　public void testDeathLoop() {
　　new Calculator().deathLoop();
　　}
　　單元測試運(yùn)行結(jié)果：java.lang.Exception: test timed out after 1000 milliseconds
　　at test.Calculator.deathLoop(Calculator.java:25)
　　at test.CaculatorTest.testDeathLoop(CaculatorTest.java:26)
　　at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
　　at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
　　…………………………