}
menubar = view.getJMenuBar();
}
public void testFileIsFirstMenu() {
JMenu file = menubar.getMenu(0);
assertEquals(\"File\", file.getText());
}
public void testEditIsSecondMenu() {
JMenu edit = menubar.getMenu(1);
assertEquals(\"Edit\", edit.getText());
}
public void testHelpIsLastMenu() {
JMenu help = menubar.getMenu(menubar.getMenuCount()-1);
assertEquals(\"Help\", help.getText());
}
// Tests for other menus...
}
與典型的 test-first 編程不同，我在此處編寫了很多測試代碼卻沒有必要編寫任何模型代碼。標準的 TDD 只編寫能夠使一個測試失敗的足夠多的代碼。然后，它就切換到模型代碼中直到測試通過為止。我并不是說 TDD 原則是錯誤的，但當兩百萬行的遺留模型代碼已經存在時，它的確不能成為一個有用的選擇。那時的目的是為了盡快地獲得盡可能大的覆蓋率。
測試還是調試？
如果遺留系統是一個好的系統，您的大多數測試還是很有希望通過的。盡管如此，您也會找到 bug。當測試一個以前從未經過測試的代碼基礎時，這種情況很可能很快就出現而不是以后才出現。這時，標準的 TDD 方法是停止測試并且開始進行修改直到測試通過。然而，這是假設您已經測試了模型中的其他所有內容并且相當自信如果您的修改中斷了系統中的其他部分，您可以立即發現。在遺留測試中，這不是一個安全的方法。在修改一個以前的 bug 時，您很有可能將一個新的 bug 引入未經測試的代碼中；而且假如這樣的話，您可能不能立即注意到這個新 bug。因此，強烈建議首先編寫更多的測試，稍后再對 bug 進行修復。歸根結底，這是一種基于如下一些因素的判斷調用：
bug 是不是看起來簡單、明顯并且是局部的？
您是否理 bug 出現的那段代碼？
您是否理解所作的修復？
如果上面問題的回答都是 “是”，那么就去修復這個 bug。如果回答是 “否”，則應該在修復改代碼之前首先盡力擴充測試套件。
通過功能劃分進行測試
在最高層次上開始測試能夠以最快速度獲得代碼覆蓋率。對于遺留代碼，應該考慮應用程序在做什么而不是考慮單個方法。盡量為它所做的每件事編寫測試。對于一個 GUI 應用程序如 jEdit，菜單項提供應用程序功能的一個好的典型。激活每個菜單并且證實它做了應該做的。例如，清單 3 展示了這樣的測試，向一個窗口輸入一些文本，激活 \"select all\" 菜單項，剪切所選中的文本，然后驗證文本在剪貼板中，而不在窗口中： 清單 3. 測試 jEdit 菜單
public void testCut() {
JEditTextArea ta = view.getTextArea();
ta.setText(\"Testing 1 2 3\");
JMenu edit = menubar.getMenu(1);
JMenuItem selectAll = edit.getItem(8);
selectAll.doClick();
JMenuItem cut = edit.getItem(3);
cut.doClick();
assertEquals(\"\", ta.getText());
assertEquals(\"Testing 1 2 3\", getClipboardText());
}
private static String getClipboardText() {
Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
Transferable contents = clipboard.getContents(null);
文章來源于領測軟件測試網 http://www.kjueaiud.com/
