2015-10-20 105 views
-2

嗨,大家好我開始學習單元測試或TDD。單元測試原理

我對C#的一些經驗,所以我與後續環節

https://msdn.microsoft.com/en-us/library/dd264975.aspx

按照樣品開始,到目前爲止,一切順利。

但是當我自己開始第一個方法時,

我有一些問題。

我寫了一個名爲「登錄」的方法

它會創建一個時間戳

例如.txt文件,我叫日誌(「一些事錯誤」)之後;

它會創建一個文件201510210030.txt

的內容爲「[2015年10月21日0時30分四十七秒]一些事錯誤」

如何測試呢?

我可以讀取日誌文件嗎?

但每次我更改文件名時,

也許我會改變對其他情況的褶皺現在的位置。

或者,也許我會改變日誌,數據庫或一些記錄服務器(國際奧委會)

如何測試呢?連接到數據庫或記錄器服務器?讀取文件?

如果該方法失敗(數據庫關閉或文件身份驗證失敗balabala),則可能性過大。

它不是真正的「單位」夠了,所以...我怎麼測試這樣的方法,

或者只是一些概念,我不單元測試瞭解。

非常感謝。

回答

1

隨着單元測試(與所有的東西一樣),你需要務實。瞄準100%代碼覆蓋率基準總是很好的,但這往往是不切實際的。在您開始將實際數據庫或文件系統引入到測試中的那一刻,您已經離開了單元測試領域並進入了集成測試。集成測試絕對沒有錯,但重要的是不要混淆兩者。

我會推薦的是確保你有它自己的獨立類中的所有日誌邏輯提供給你正在通過依賴注入測試的類(你提到IoC,所以我假設你很熟悉)。一旦你這樣做了,你可以傳遞一個模擬的「記錄器」到你的類中,根本不接觸文件系統。這將確保您正在測試的類將處理實現該「Logger」界面的任何內容。

如果你正在尋找實際單元測試記錄儀本身,那麼恐怕這是不可能的。記錄器與文件系統(或數據庫)緊密耦合,因此您無法真正進行單元測試。你總是可以把所有的持久化邏輯提取到另一個類中,然後模擬出來,但是你只能把問題推回去。在應用程序和基礎架構之間總會有一堵牆,在兩者緊密結合的地方。重要的是讓處理這種交互的類相對簡單,並確保它使用集成測試進行測試。

+0

非常有幫助,謝謝 –