TDD在文本文件導入項目

Question

我剛剛開始，是的，我還沒有寫任何測試（我不是一個原教旨主義者，我不喜歡編譯錯誤，因爲沒有測試），但是我想知道從哪裏開始做一個項目，該項目根據XML映射將固定長度的平面文件記錄解析爲代表所有文件佈局超集的類，然後將類細節寫入（通過轉換）到數據庫表。

有這麼多的外部因素，我不想嘲笑他們，所以在哪裏或如何將是一個好方法開始測試駕駛這個項目？

Answer 1

這就是把問題分解成部分。一些例子：

• 文件/流閱讀
• 輸入映射
• 輸入映射裝載機
• 文件佈局
• 文件佈局集合
• 數據訪問層

儘量給每個類都有一個單獨的責任，確定它的依賴關係，並將其注入在模擬/存根的幫助下，將允許您單獨測試每個類。

Answer 2

那麼，你想做測試，但你不想嘲笑。我相信它會讓你編寫integration tests或acceptance tests。這意味着你必須在你的測試中做很多設置，這可能會讓你的測試變得脆弱而難以維護。

我真的會推薦嘲笑你的外部依賴。它會使你的應用鬆散地結合在一起，我相信未來會更容易維護。再加上你的測試將變得更易於管理。

在那裏有很多Mock Frameworks可以幫助你。我不得不承認，如果你從來沒有這樣做過，那就有一些學習曲線。但我們從事軟件開發業務，總是有一些新的東西需要學習。

如果您決定投入一些時間學習模擬測試，您可以從this article開始。

祝你好運。

Answer 3

兩種技術，我發現有用的測試基於IO-類：

• 如果可能的話，說話像StreamReader和Stream而不是文件名一般條款。在測試中創建StringReader或MemoryStream很容易，並以這種方式提供數據。
• 有時你需要更多的數據，而不是真的想要在代碼中嵌入文字。在這種情況下，將測試文件（有時是輸入和期望輸出）添加爲嵌入式資源，並使用Assembly.GetManifestResourceStream來獲取執行時的數據。

除了這些一般的觀點，TrueWill的建議聽起來非常好。如果你可以分開更大的任務，爲每個單獨的位寫單元測試聽起來好像很容易 - 除了數據庫訪問之外，這通常很痛苦。如果您可以使數據庫部分儘可能小，從另一個易於測試的課程中提供所有數據，這應該使生活變得更簡單。