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