而調用代碼的運行程序應該盡可能地設計成一行，以減少與被測試代碼的關聯，這可以有效避免對邊緣效應與不穩定實現細節的依賴。測試的檢查階段是最復雜的，因為這個階段經常需要添寫非測試用代碼。測試時可能需要對結果進行嚴格的分析以確保其符合要求。有時甚至需要將這個過程分為幾步來完成，以取得測試可以識別的結果。在XSL轉換中，這兩種情況都是可能的，結果儲存在文件中，然后以XML格式讀入內存并進行準確性分析。
Saxon中有個相對簡單的例子。已有XML文件和XPath表達式的情況下，Saxon可以執行表達式并返回匹配列表。Saxon中的XpathExample樣本類就是用來執行這種任務的�；谝陨戏治�，可以設計如下的測試流程：
public void testXPathEvaluation() {
//initialize
XPathEvaluator xpe = new XPathEvaluator(
new SAXSource(new InputSource("/path/to/file.xml")));
XPathExpression findLine =
xpe.createExpression("/some/xpath[expression]");
//work
List matches = findLine.evaluate();
//check
assertTrue(matches.count() > 0);
}
兩次輸入的都是字符串常量，輸出的則是所匹配的列表，可以用來驗證匹配結果的正確性。這些工作都由一行代碼完成，這行代碼只是簡單地調用了被測試的方法。
另一種可能的情況是XPathEvaluator沒有調用createExpression()方法。因為表達式不存在，這時可能會顯示錯誤信息。
將輸入的源文件名和表達式保留在測試用例中不是個好習慣。某些項目(服務器名、用戶名和密碼等)不應該出現在測試文件中，它們應該可以根據情況自由設置。并且，測試用例的設計應該方便測試驅動和測試數據的分離、測試驅動對大范圍數據的可重用性和測試數據對測試驅動的可重用性。另一方面，不要將一個簡單的測試用例實現設計地過于復雜。一般來說，測試用例已經說明了系統的大部分狀態，并可對其進行參數描述，所以無需在測試中進行過于詳細的參數描述。
許多代碼段可能出現在不止一個測試用例中。有經驗的面向對象開發人員會嘗試對其進行重構并創建通用類和有效方法。有時候這樣做非常有用，比如登錄過程應該設計成所有測試用例可用的方法。 但是，不要過度設計測試，這些Java類僅僅是用來驗證應用程序的功能行為而已。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
