我有多種測試用例使用通用方法的情況。所以爲了避免DRY(不要重複自己),我把它們放到util類中。所以現在我需要爲util類編寫一個測試用例。所有util類包含正在讀取特定文件並返回其內容。我是否需要爲測試用例使用的util類編寫測試用例
感謝, 斯利拉姆
我有多種測試用例使用通用方法的情況。所以爲了避免DRY(不要重複自己),我把它們放到util類中。所以現在我需要爲util類編寫一個測試用例。所有util類包含正在讀取特定文件並返回其內容。我是否需要爲測試用例使用的util類編寫測試用例
感謝, 斯利拉姆
的一般規則是:測試你需要,直到你滿意,你的程序是正確的一樣多。
用於測試的錯誤實用程序類如何影響程序的行爲?我不知道你的特定程序,但是一個不正確的測試工具類不會影響你程序的正確性。相反,它可以讓你認爲你的程序是正確的,但實際上並不正確,或者認爲它是不正確的。所以我的實用工具類測試的本能是而不是直接測試類,但要通過心理證明過程,並確定效用方法是正確的,因此不會欺騙我對程序正確性的錯誤信念。
尤其是在您的情況下,實用程序類只讀取文件並返回其內容,您可能不需要編寫測試用例。編碼這個簡單的應該很容易驗證是否正確,所以精神證明正確性比編寫測試用例要便宜。
N.B.通過所有代碼的心理證明過程是相當有用的。一些調試的時髦「技巧」,如rubber duck debugging,實際上只是強迫自己證明(至少在你腦海中)你的代碼部分是正確的,或者至少沒有公然錯誤的方法。
好吧,TDD總是說我們需要獲得100%的代碼覆蓋率?我的意思是說,如果開發人員有權決定什麼是重要的測試,什麼不重要,我認爲這是危險的。因爲開發人員畢竟是人,容易出錯?你說什麼? – sriram 2012-04-10 05:42:50
@sriram TDD的目標不是100%的代碼覆蓋 - 它是正確的代碼。 100%的代碼覆蓋是*達到目的的手段*,而不是本身的目的。開發人員是人爲的,容易出錯,但如果你能證明正確性,無論是精神上還是永久形式(評論,論文等),你都有比單元測試更好的東西。單元測試顯示單元測試傳遞給您正在測試的代碼的輸入的正確性,但是正確性的證明顯示*所有輸入*的正確性,這是嚴格更好的。 – 2012-04-10 05:47:18
謝謝!完全同意。 – sriram 2012-04-10 06:01:29