開發(fā)人員可以使用 assumeThat 并配合 hamcrest 的匹配符 Matcher，對即將被傳入到單元測試用例函數(shù)中的 runtime 變量值做精確的假設(shè)，如果假設(shè)不正確（即當(dāng)前 runtime 變量的取值不滿足所假設(shè)的條件），則不會將該變量傳給該測試用例中假設(shè)后面的語句，即程序會從該 assumeThat 所在的 @Test 測試函數(shù)中直接自動跳出（test automatically quietly passes，values that violate assumptions are quietly ignored），去執(zhí)行下一個 @Test 函數(shù)，使得本來會中斷的測試現(xiàn)在不會中斷。
使用假設(shè)機(jī)制必須得注意以下幾點：
由于 JUnit 4.4 引用了 Hamcrest 匹配符庫，所以使用 assumeThat 可以編寫所有的假設(shè)語句。但是為了方便使用，JUnit 4.4 除 assumeThat 之外，還提供了 assumeTrue，assumeNotNull 和 assumeNoException 語句。 要使用 assume* 假設(shè)語句，必須得 import static org.junit.Assume.*;。 如果引用了第三方 hamcrest 的匹配符庫，必須得 import static org.hamcrest.Matchers.*;，如果引用 JUnit 4.4 自帶的匹配符庫，需要 import static org.hamcrest.CoreMatchers.*;。
清單 8 假設(shè)機(jī)制使用舉例
例1：
@Test
public void filenameIncludesString() {
//如果文件分隔符不是’/’(forward slash)，則不執(zhí)行assertThat斷言測試，直接跳過該測試用例函數(shù)
assumeThat(File.separatorChar， is('/'));
//判斷文件名fileName是否含有字符串"developerWorks"
assertThat( fileName， containsString( "developerWorks" ) );
}
例2：
@Test
public void filenameIncludesString() {
//bugFixed不是JUnit4.4的函數(shù)，是開發(fā)人員自己工程中定義的函數(shù)，表示判斷指定的defect是否
//被修正了，如果被修正，則返回true，否則返回false。這里假設(shè)缺陷13356被修正后才進(jìn)行余下單元測試
assumeTrue( bugFixed("13356") );
//判斷文件名fileName是否含有字符串"developerWorks"
assertThat( fileName， containsString( "developerWorks" ) );
}
理論機(jī)制（Theory）
為什么要引用理論機(jī)制（Theory）
當(dāng)今軟件開發(fā)中，測試驅(qū)動開發(fā)（TDD — Test-driven development）越發(fā)流行。為什么 TDD 會如此流行呢？因為它確實擁有很多優(yōu)點，它允許開發(fā)人員通過簡單的例子來指定和表明他們代碼的行為意圖。
TDD 的優(yōu)點：
使得開發(fā)人員對即將編寫的軟件任務(wù)具有更清晰的認(rèn)識，使得他們在思考如何編寫代碼之前先仔細(xì)思考如何設(shè)計軟件。 對測試開發(fā)人員所實現(xiàn)的代碼提供了快速和自動化的支持。 提供了一系列可以重用的回歸測試用例（regression test case），這些測試用例可以用來檢測未來添加的新代碼是否改變了以前系統(tǒng)定義的行為（測試代碼兼容性）。
然而，TDD 也同樣具有一定的局限性。對于開發(fā)人員來說，只用一些具體有限的簡單例子來表達(dá)程序的行為往往遠(yuǎn)遠(yuǎn)不夠。有很多代碼行為可以很容易而且精確的用語言來描述，卻很難用一些簡單的例子來表達(dá)清楚，因為他們需要大量的甚至無限的具體例子才可以達(dá)到被描述清楚的目的，而且有時有限的例子根本不能覆蓋所有的代碼行為。
以下列出的代碼行為反映了 TDD 的局限性：
將十進(jìn)制整數(shù)轉(zhuǎn)換成羅馬數(shù)字，然后再將其轉(zhuǎn)換回十進(jìn)制數(shù)，并保持原有的數(shù)值。（需要大量的測試用例，有限的測試數(shù)據(jù)可能測不出所實現(xiàn)的代碼的錯誤）。 對一個對象進(jìn)行操作，希望結(jié)果仍然等于原來的對象。（需要考慮各種各樣類型的對象） 在任何一個貨幣的 collection 中添加一個對象 dollar，需要產(chǎn)生出另外一個新的與以前不同的 collection 。（需要考慮所有的 collection 類型的對象）。
理論（Theory）的出現(xiàn)是為了解決 TDD 這個問題。 TDD 為組織規(guī)劃開發(fā)流程提供了一個方法，先用一些具體的例子（測試用例 test case）來描述系統(tǒng)代碼的行為，然后再將這些行為用代碼語句進(jìn)行概括性的總的陳述（代碼實現(xiàn) implementation）。而 Theory 是對傳統(tǒng)的 TDD 進(jìn)行一個延伸和擴(kuò)展，它使得開發(fā)人員從開始的定義測試用例的階段可以通過參數(shù)集（理論上是無限個參數(shù)）對代碼行為進(jìn)行概括性的總的陳述，我們叫這些陳述為理論。理論是對那些需要無窮個測試用例才能正確描述的代碼行為的概括性陳述。結(jié)合理論（Theory）和測試一起，可以輕松的描述代碼的行為并發(fā)現(xiàn) BUG .開發(fā)人員都知道他們代碼所想要實現(xiàn)的概括性的總的目的，理論使得他們只需要在一個地方可以快速的指定這些目的，而不要將這些目的翻譯成大量的獨立的測試用例。
