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