如何測試文件操作

Question

我聽說在測試中訪問數據庫是錯誤的。

但是文件操作呢？例如，FileUtils中的cp,mv,rm和touch方法。

如果我編寫測試並實際運行命令（移動文件，重命名文件，製作目錄等），我可以測試它們。但是我需要在再次運行測試之前「撤銷」我運行的每個命令。所以我決定編寫所有代碼來「撤消」，但這似乎浪費時間，因爲我並不需要「撤消」。

我真的很想看看別人怎麼做。例如，如果您生成大量靜態文件，您將如何測試？

Answer 1

在你的情況下訪問文件是完全合法的，如果你正在編寫文件操作代碼，它應該在文件上測試。你必須小心的一件事是，失敗的測試意味着你的代碼是錯誤的，而不是有人刪除了測試所需的文件或類似的東西。我會將目錄和測試所需的文件放在一個僅用於測試的單獨文件夾中。然後在建立測試拷貝的整個文件夾到臨時的地方做所有的測試，然後在測試之後刪除臨時文件。通過這種方式，每個測試都有一份乾淨的測試文件副本。

Answer 2

也許你可以在名爲「test_ *」的測試包中創建一個目錄。然後，您將更改的文件放在此目錄中（例如：如果創建目錄，則將在測試目錄內創建目錄）。在測試結束時，你可以刪除這個目錄（只有一個命令）。這是您將執行的獨特的UNDO操作。

您將把所需的所有文件放到測試包中的測試目錄中。

Answer 3

訪問像數據庫，文件系統，SMTP服務器等資源是單元測試壞主意。在某些時候，顯然你必須用真實的文件來試用它，這是一種不同的測試，一種集成測試。集成測試更加痛苦，您必須小心確保您的測試從一個明確定義的狀態開始，並且在您訪問真正的文件系統後，它們將運行得更慢。另一方面，你不應該像單元測試那樣頻繁地運行它們。

對於單元測試，您應該能夠利用鴨子打字來創建對與您使用的文件對象具有相同方法的對象有反應的對象。另外，這種方法沒有什麼可以撤消的，測試的運行速度會快很多。

Answer 4

訪問數據庫不是「錯誤的測試」。您還將如何測試代碼與數據庫的集成？

可重複測試的關鍵是一致的環境。只要您從測試的相同文件系統或數據庫內容開始，您應該沒有錯。這通常是在測試套件開始時通過清理過程處理的。

Answer 5

「純」單元測試應not access "expensive" resources如文件系統，數據庫...

現在你可能要運行的「一體化」的測試在同一時間爲您的單元測試（或任何你給他們打電話） ，並使用相同的框架，這很方便。

您可以將一組文件用於單元測試，您可以像Janusz的答案中所建議的那樣將其複製到臨時位置，或者在單元測試中生成這些文件，也可以在單元測試時使用mock of the FileUtils而不是真正的FileUtils。

Answer 6

如果您的操作系統支持基於RAM的文件系統，則可以使用其中的一種。這甚至具有代碼中的偶爾`unix command`繼續工作的優勢。