單元測試中的文件訪問不好？

Question

編寫處理XML的單元測試（例如，測試讀取/生成XML的類）時，我用單元測試旁邊的單獨文件將我的斷言結果XML-String/my XML XML字符串寫入。比方說，我有一個「MyTransformer」類將一種XML格式轉換爲另一種格式。然後我會在同一個包創建三個文件都：

• MyTransformerTest.java
• MyTransformerTestSampleInput.xml
• MyTransformerTestExpectedOutput.xml

然後我的說法，可能是這樣的（簡化的僞代碼爲了簡單起見）：

Reader transformed = MyTransformer.transform(getResourceAsStream("MyTransformerTestSampleInput.xml"))); 
Reader expected = getResourceAsStream("MyTransformerTestExpectedOutput.xml"); 
assertXMLEqual(expected, transformed); 

然而，一個colle ague告訴我，我在這個單元測試中的文件訪問是不可接受的。他建議創建一個包含我的XML文件內容的字符串常量（private static final String），可能在單獨的groovy類中，因爲多行字符串的好處而不是將XML文件寫入文件。

我不喜歡字面字符串常量的想法，因爲即使我在groovy中有多行字符串，我仍然會丟失語法突出顯示和XML編輯器的所有其他有用功能，這些功能會立即告訴我，如果我的XML有語法錯誤等。

您怎麼看？文件訪問是否真的很糟糕？如果是這樣：爲什麼？如果不是，爲什麼它可以嗎？

Answer 1

兩個問題，文件中的單元測試：

• 他們放慢了測試周期。您可能有數千個單元測試，最好在每個構建中運行 - 因此它們應該儘可能快。如果你能加快速度（例如，通過擺脫I/O操作），你會想要做到這一點。當然這並不總是可行的，所以你通常會通過NUnit [Category]或類似的東西分離出「慢速」測試，然後再少運行一次這些特殊測試 - 比如只在Nightly builds上。
• 他們引入額外的依賴關係。如果一個測試需要一個文件，它不僅會在測試背後的邏輯錯誤，而且文件丟失，或者測試運行器沒有讀取權限等時失敗。這使得調試和修復不那麼令人愉快！

這就是說，我不會過於嚴格地在測試中不使用文件。如果可能，儘量避免它們，但不要生氣。確保考慮可維護性和速度 - 測試越乾淨，以後修復和理解測試越容易。

Answer 2

如果您的單元測試訪問文件以將假測試數據提供給被測系統，那麼您可以運行測試，這不是問題。這實際上可以幫助您在測試系統內運用更多種類的測試數據。

但是，如果您的System Under Test訪問文件系統，則在執行測試時，這不是單元測試。這是一個集成測試。這是因爲您正在訪問諸如文件系統等橫切關注點，並且它們不能歸類爲單元測試。

你真的會隔離/僞造文件訪問並使用單元測試來測試代碼的行爲（如果有的話）。他們更快，更容易運行。如果寫得正確，它會提供針點反饋。

Answer 3

在這些情況下，我有一個單元測試，它使用文件的內部表示，在這種情況下，它是一個字符串文字。

我還會有一個集成測試，以便在寫入文件時測試代碼是否正常工作。

所以這一切都歸結於單元/集成測試定義。兩者都是有效的測試，只取決於你當時正在寫什麼測試。