如何編寫「髒」單元測試？

我在閱讀Code Complete。在那本書中，史蒂夫麥康奈爾警告說：「開發者測試往往是'乾淨的測試'。開發人員傾向於測試代碼是否工作（乾淨測試），而不是測試代碼中斷的所有方式（髒測試）。「如何編寫「髒」單元測試？

如何爲代碼破解的方式編寫測試？我的意思是，我可以爲不良輸入編寫測試，並確保它被正確阻止。但除此之外，我應該考慮什麼樣的事情？麥康奈爾在這裏的含義是什麼？我很喜歡基本的單元測試，但是試圖掌握它。

2012-06-28 bernie2436

如果您不這樣做：傳遞以null結尾的字符串'「\ 0」'作爲方法參數。也許看看像[PEX]（http://research.microsoft.com/en-us/projects/pex/）這樣的工具，它們在自動測試邊緣案例方面做得很好。 – Filburt

我認爲你在這裏正確的道路上。測試證明代碼的工作原理將調用一個合理，有意義和預期輸入的方法，程序處於正常狀態。雖然測試打破代碼嘗試認爲「開箱即用」關於這段代碼，因此使用任何無意義或意想不到的輸入。

恕我直言重要的是什麼雖然是瞭解這兩個思維過程是非常不同的。當開發人員以TDD方式編寫代碼時，他傾向於專注於在代碼中實現的各種功能部分，並且測試證明此功能或用例的某些功能或指定功能可以正常工作。以這種方式創建的測試是McConnell所說的「乾淨測試」。

思考一段代碼如何被破壞需要一個非常不同的思維過程和不同的體驗。它需要從不同的角度來看你的方法和API，例如暫時擱置你所知道的目標的這些方法和參數，並且只關注在技術上可行的與他們做的。還要考慮所有這些 - 通常是隱含的 - 前提條件或依賴關係，這種方法才能正常工作。它取決於從DB讀取的配置參數嗎？它是否寫入文件系統？它是否調用另一個組件，期望它事先被正確初始化？它使用大量的內存嗎？它是否在GUI上顯示消息？......如果其中一個或多個不成立，該怎麼辦？

所有這些導致重要的問題：你的方法應該如何處理這種髒案件？它應該崩潰嗎？拋出異常？繼續儘可能好？返回錯誤代碼？記錄錯誤報告？......所有這些小或更大的決定對於正確和一致地定義方法或API的合同非常重要。

肯特貝克談到在同一種意義上佩戴「開發人員帽子」和「測試人員帽子」之間的切換。流暢地切換觀點和思維過程需要練習和經驗。

來源

2012-06-28 15:53:07

作者最有可能意味着什麼清潔測試是僅驗證方法執行的happy path的測試。

測試開心路徑通常是最簡單的，人們可能會認爲起作用，他們的寫作測試工作已經完成。情況很少如此。試想一下：

public void SaveLog(string entry) 
{ 
    var outputFile = this.outputFileProvider.GetLogFile(); 
    var isValid = this.logValidator.IsValid(outputFile); 
    if (isValid) 
    { 
     this.logWriter.Write(outputFile, entry); 
    } 
}

快樂路徑測試將簡單地假定所有的依賴關係（outputFileProvider，logValidator，logWriter）工作，寫確實正在發生。但是，有很大的可能性可能會沿途破壞，而那些路徑也應該被測試。像：

outputFileProvider無法獲取輸出文件
outputFile被證明是無效的
logValidator失敗，自己的異常
logWriter無法寫入

只是僅舉幾例！單元測試比單純檢查快樂路徑還多，但不幸的是情況往往如此。

來源

2012-06-28 15:56:41

Elisabeth Hendrickson，Test Obsessed，有一個Test Heuristics Cheat Sheet，其中她列出了各種的測試方法。該文件廣泛地涉及測試，但名爲「數據類型攻擊」的部分有很多具體的例子，「不愉快的路徑」單元測試可以看。

例如，這裏有她對方法測試的路徑和文件的想法：在名稱

長名稱（> 255個字符）
特殊字符（空格*/\ | <>，（？。）[] {};：'「 @＃$％^ &）
不存在的
已經存在
沒有空間
最小的空間
寫保護
不可用
鎖定
在損壞
遠程計算機
！

來源

2012-06-28 18:17:18 JeffH

如何編寫「髒」單元測試？

回答

相關問題