別擔心你要敲的字符量，以后在IDE中，只要點幾下鼠標成了。運行結(jié)果應該如下所示，表明執(zhí)行了一個測試，并通過了測試：
.
Time: 0
OK (1 tests)
如果我們將Car.getWheels()中返回的的值修改為3，模擬出錯的情形，則會得到如下結(jié)果：
.F
Time: 0
There was 1 failure:
1) testGetWheels(testCar)junit.work.AssertionFailedError: expected:<4> but was:<3>
at testCar.testGetWheels(testCar.java:37)
FAILURES!!!
Tests run: 1， Failures: 1， Errors: 0
注意：Time上的小點表示測試個數(shù)，如果測試通過則顯示OK。否則在小點的后邊標上F，表示該測試失敗。注意，在模擬出錯的測試中，我們會得到詳細的測試報告“expected:<4> but was:<3>”，這足以告訴我們問題發(fā)生在何處。下面是你調(diào)試，測試，調(diào)試，測試...的過程，直至得到期望的結(jié)果。

Design by Contract（這句話我沒法翻譯）
Design by Contract本是Bertrand Meyer（Eiffel語言的創(chuàng)始人）開發(fā)的一種設(shè)計技術(shù)。我發(fā)現(xiàn)在JUnit中使用Design by Contract會帶來意想不到的效果。Design by Contract的核心是斷言（assersion）。斷言是一個布爾語句，該語句不能為假，如果為假，則表明出現(xiàn)了一個bug。Design by Contract使用三種斷言：前置條件（pre-conditions）、后置條件（post-conditions）和不變式（invariants）這里不打算詳細討論Design by Contract的細節(jié)，而是希望其在測試中能發(fā)揮其作用。
前置條件在執(zhí)行測試之前可以用于判斷是否允許進入測試，即進入測試的條件。如 expectedWheels > 0， myCar != null。后置條件用于在測試執(zhí)行后判斷測試的結(jié)果是否正確。如 expectedWheels==myCar.getWheels()。而不變式在判斷交易(Transaction)的一致性（consistency）方面尤為有用。我希望JUnit可以將Design by Contract作為未來版本的一個增強。

Refactoring（這句話我依然沒法翻譯）
Refactoring本來與測試沒有直接的聯(lián)系，而是與軟件熵有關(guān)，但既然我們說測試能解決軟件熵問題，我們也必須說出解決之道。（僅僅進行測試只能發(fā)現(xiàn)軟件熵，Refactoring則可解決軟件熵帶來的問題。）軟件熵引出了一個問題：是否需要重新設(shè)計整個軟件的結(jié)構(gòu)？理論上應該如此，但現(xiàn)實不允許我們這么做。這或者是由于時間的原因，或者是由于費用的原因。重新設(shè)計整個軟件的結(jié)構(gòu)會給我們帶來短期的痛苦。而不停地給軟件打補丁甚至是補丁的補丁則會給我們帶來長期的痛苦。（不管怎樣，我們總處于水深火熱之中）
Refactoring是一個術(shù)語，用于描述一種技術(shù)，利用這種技術(shù)我們可以免于重構(gòu)整個軟件所帶來的短期痛苦。當你refactor時，你并不改變程序的功能，而是改變程序內(nèi)部的結(jié)構(gòu)，使其更易理解和使用。如：該變一個方法的名字，將一個成員變量從一個類移到另一個類，將兩個類似方法抽象到父類中。所作的每一個步都很小，然而1－2個小時的Refactoring工作可以使你的程序結(jié)構(gòu)更適合目前的情況。Refactoring有一些規(guī)則：
1> 不要在加入新功能的同時refactor已有的代碼。在這兩者間要有一個清晰的界限。如每天早上1-2個小時的Refactoring，其余時間添加新的功能。
2> 在你開始Refactoring前，和Refactoring后都要保證測試能順利通過。否則Refactoring沒有任何意義。
3> 進行小的Refactoring，大的不是Refactoring了。如果你打算重構(gòu)整個軟件，沒有必要Refactoring了。
只有在添加新功能和調(diào)試bug時才又必要Refactoring。不要等到交付軟件的后關(guān)頭才Refactoring。那樣和打補丁的區(qū)別不大。Refactoring 用在回歸測試中也能顯示其威力。要明白，我不反對打補丁，但要記住打補丁是應該后使用的必殺絕招。（打補丁也需要很高的技術(shù)，詳情參看微軟網(wǎng)站）

IDE對JUnit的支持
目前支持JUnit的Java IDE 包括 IDE 方式 個人評價（1－5，滿分5）
Forte for Java 3.0 Enterprise Edition plug-in 3
JBuilder 6 Enterprise Edition integrated with IDE 4
Visual Age for Java support N/A
在IDE中如何使用JUnit，是非常具體的事情。不同的IDE有不同的使用方法。一旦理解了JUnit的本質(zhì)，使用起來十分容易了。所以我們不依賴于具體的IDE，而是集中精力講述如何利用JUnit編寫單元測試代碼。心急的人可參看資料。

JUnit簡介
既然我們已經(jīng)對JUnit有了一個大致的了解，我希望能給大家提供一個稍微正式一些的編寫JUnit測試文檔的手冊，明白其中的一些關(guān)鍵術(shù)語和概念。但我要聲明的是這并不是一本完全的手冊，只能認為是一本入門手冊。同其他OpenSource的軟件有同樣的問題，JUnit的文檔并沒有商業(yè)軟件文檔的那種有規(guī)則，簡潔和完全。由開發(fā)人員編寫的文檔總是說不太清楚問題，全整的文檔需要參考"官方"指南，API手冊，郵件討論組的郵件，甚至包括源代碼中及相關(guān)的注釋。
事實上問題并沒有那么復雜，除非你有非常特別的要求，否則，只需參考本文你可以得到所需的大部分信息。