別擔心你要敲的字符量，以后在IDE中，只要點幾下鼠標就成了。運行結果應該如下所示，表明執行了一個測試，并通過了測試：
.
Time: 0
OK (1 tests)
如果我們將Car.getWheels()中返回的的值修改為3，模擬出錯的情形，則會得到如下結果：
.F
Time: 0
There was 1 failure:
1) testGetWheels(testCar)junit.framework.AssertionFailedError: expected:<4> but was:<3>
at testCar.testGetWheels(testCar.java:37)
FAILURES!!!
Tests run: 1, Failures: 1, Errors: 0
注意：Time上的小點表示測試個數，如果測試通過則顯示OK。否則在小點的后邊標上F，表示該測試失敗。注意，在模擬出錯的測試中，我們會得到詳細的測試報告“expected:<4> but was:<3>”，這足以告訴我們問題發生在何處。下面就是你調試，測試，調試，測試...的過程，直至得到期望的結果。
Design by Contract(這句話我沒法翻譯)
Design by Contract本是Bertrand Meyer(Eiffel語言的創始人)開發的一種設計技術。我發現在JUnit中使用Design by Contract會帶來意想不到的效果。Design by Contract的核心是斷言(assersion)。斷言是一個布爾語句，該語句不能為假，如果為假，則表明出現了一個bug。Design by Contract使用三種斷言：前置條件(pre-conditions)、后置條件(post-conditions)和不變式(invariants)這里不打算詳細討論Design by Contract的細節，而是希望其在測試中能發揮其作用。
前置條件在執行測試之前可以用于判斷是否允許進入測試，即進入測試的條件。如 expectedWheels > 0, myCar != null。后置條件用于在測試執行后判斷測試的結果是否正確。如 expectedWheels==myCar.getWheels()。而不變式在判斷交易(Transaction)的一致性(consistency)方面尤為有用。我希望JUnit可以將Design by Contract作為未來版本的一個增強。
Refactoring(這句話我依然沒法翻譯)
Refactoring本來與測試沒有直接的聯系，而是與軟件熵有關，但既然我們說測試能解決軟件熵問題，我們也就必須說出解決之道。(僅僅進行測試只能發現軟件熵，Refactoring則可解決軟件熵帶來的問題。)軟件熵引出了一個問題：是否需要重新設計整個軟件的結構?理論上應該如此，但現實不允許我們這么做。這或者是由于時間的原因，或者是由于費用的原因。重新設計整個軟件的結構會給我們帶來短期的痛苦。而不停地給軟件打補丁甚至是補丁的補丁則會給我們帶來長期的痛苦。(不管怎樣，我們總處于水深火熱之中)
Refactoring是一個術語，用于描述一種技術，利用這種技術我們可以免于重構整個軟件所帶來的短期痛苦。當你refactor時，你并不改變程序的功能，而是改變程序內部的結構，使其更易理解和使用。如：該變一個方法的名字，將一個成員變量從一個類移到另一個類，將兩個類似方法抽象到父類中。所作的每一個步都很小，然而1-2個小時的Refactoring工作可以使你的程序結構更適合目前的情況。Refactoring有一些規則：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
