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類僅僅是用來驗證應用程序的功能行為而已。
測試用例是脆弱的。比如,如果開發人員更改了testXPathEvaluation測試中輸入文件的位置,或者creatExpression方法簽名有所變動,測試腳本就會失效。
對于應用程序的測試用例實現來說,大量的重復性工作與改動是不可避免的。因此,可跟蹤性對于所有的測試用例都是至關緊要的。出現問題的時候,如果能為開發人員指出相應的測試用例說明和用例說明將有利于提高修正bug的速度。
因此,測試用例注釋中應標明原始說明文檔的引用位置。這可以是一個簡單的代碼注釋,也可以對每條測試都注釋相關用例和所測功能,這樣當測試出現問題時開發人員就會收到一條相關信息。因此,在代碼中加入參考并維護可追蹤性是很重要的。
設計運行時事件表
要了解測試覆蓋的范圍,必須先了解所測試代碼如何運行,以及各種靜態類如何形成描述程序狀態的動態對象圖表。
有許多模擬這種行為的方法,包括Granovetter圖和物件互動圖。其基本思想是用圖形化的方式研究代碼以了解測試中涉及到的運行時部分。這些技術都可用運行時事件表(Runtime Event Diagrams)來描述,因為這些圖表顯示了程序運行時發生的事件,而非理論上類可以控制的事件。這些圖表非常重要的原因包括:
首先,這些圖表便于從高層上理解代碼,并提供有用的說明文檔。這個文檔與代碼的內聯文檔不同。這些圖表顯示代碼的運行時表現,是產生代碼功能的地方,也易于對系統的了解;大多數設計模式和架構在用對象和參考表示時要比用類和域表示容易得多。
另外,這些圖表將測試執行的代碼分類列表,并確定測試是否會受到將來對任意代碼改動的影響。如果開發人員確定測試A是建立在B、C和D的基礎上,她就可以確定如果對B、C或D做出改動就需要對A進行重新測試(確保向后兼容)。
以盡可能少的步驟模擬系統是個好方法??偟膩碚f,實際調用與此無關,重要的是系統如何作為整體運作以獲得預期目標??梢杂煤喕哪M系統實現這個目的,該系統只關心對象間的基本交互,并用自然語言描述交互中發生的事件。
做出運行時事件表后,就可以將其整合到類文檔中。需要注意的是,為表添加一些限制可使其對類的修改更有彈性。首先,一般不能使用方法名,因為它們會隨時間發生變化。取而代之的是更易理解的自然語言描述。其次,這些圖表主要是關于系統中各部分的交互。這是高層架構上的設計方案,一般不會再做改動。最后,圖表是建立在類型而非特定類的基礎上。只要基本類型不變,為維持交互協議的正常運行,這些圖表就不需要更新。
原文轉自:http://www.uml.org.cn/Test/20111142.asp