對於使用C#進行單元測試,我認爲從實現新功能或創建新解決方案的想法出發,最好先從單元測試開始。我是否應該爲已建立的代碼進行單元測試?
但是,當已經建立的完全成熟的解決方案已經建立了很少或者沒有創建單元測試的時候,當已經有足夠的異常處理時,測試的重點是什麼?
即時通訊編寫單元測試,但沒有看到點,當我不能通過格式不正確的數據ANYWAY進入任何即時測試,因爲我主要使用ENUM的!
除非我錯過了一些絕對瘋狂的東西..我是否浪費時間回到舊代碼來集成單元測試?
對於使用C#進行單元測試,我認爲從實現新功能或創建新解決方案的想法出發,最好先從單元測試開始。我是否應該爲已建立的代碼進行單元測試?
但是,當已經建立的完全成熟的解決方案已經建立了很少或者沒有創建單元測試的時候,當已經有足夠的異常處理時,測試的重點是什麼?
即時通訊編寫單元測試,但沒有看到點,當我不能通過格式不正確的數據ANYWAY進入任何即時測試,因爲我主要使用ENUM的!
除非我錯過了一些絕對瘋狂的東西..我是否浪費時間回到舊代碼來集成單元測試?
編寫針對現有代碼的單元測試對於當前或將來的工作是有幫助的。這些測試可以幫助您確保不會引入任何新bug或不願改變某些行爲。
此外,爲現有代碼編寫測試可以幫助確定可能未知或複雜實現的實際功能。
在一個不太可能的情況下,開發人員再也不會碰觸到無缺陷的軟件,因爲添加單元測試可能對您無能爲力。但在其他任何情況下,它都有助於記錄行爲併爲未來建立安全網。
呵呵,既然你提到它:使用enums
不會保護你在C#中傳遞無效參數。
不,你不會爲現有代碼編寫測試而浪費時間。如果您以任何方式維護代碼,那麼進行單元測試是個好主意。
您的主要挑戰將是工作的範圍 - 爲大量代碼編寫單元測試並不容易,當然也不好玩。我強烈建議你採取迭代方法。在最初的一輪中,關注提供良好類覆蓋率的單元測試可能是一個好主意,這是一個基本指標,也是一個很好的起點。
在達到您認爲的有意義的班級覆蓋水平之後,您可以通過代碼覆蓋將焦點擴展到其他領域。
使用像NCover這樣的覆蓋工具可以真正幫助提供一些指標。
您似乎認爲單元測試只處理無效輸入。事實並非如此。 –