2013-03-26 37 views
3

所以我讀過關於這個東西叫SOLID(混合)Writing Testable Code。然後具體關於D部分。一個人如何使用語言庫提供的原始類型或方法/類時,請遵循以下原則。SOLID和單元測試。使用語言提供的方法/類

一個是否還需要使用依賴注入的說,一個FileWriter陣列(爪哇(new int[64])或類成員?做這些需要使用DI注入或可以在類實例化還是他們?

你應該走多遠以上的指導方針?

我不是在尋找一個特定於語言的答案(如果可能的話)。恕我直言,答案應該適用於,例如PHP,Python Java,甚至C

回答

4

您通常不會注入基元或類似對象。原因是那些有:

  1. 簡單的價值持有人沒有太多的業務/域邏輯關聯
  2. 輕鬆存根無需任何額外的工具(創建測試假數據陣列是沒有問題的)

FileWriter是不同的,因爲它與上面的點完全相反。我不能簡單地將其存儲在測試中,並使其工作不會很少strong假設 - 就像我假設每個將來運行此代碼的開發人員都將在其計算機上具有某個文件。這通常是不走單元測試和爲什麼DI是在這些情況下應用的原因之一。

這些問題來自FileWriter作爲通信點這兩個不相關的組件 - 您的應用程序和文件系統。任何類在大多數情況下,做這種整合(您的應用程序和數據庫/網絡/文件/ REST之間等)應被抽象和注射。

1

注射陣列過度殺傷。作家是絕對必須的。實際上注入作者是不夠的。文件編寫者與外部世界大量交互,你不需要這些。文件編寫器應該被封裝在自己的類中,並且不會被直接調用。

相反,注入一個FileWriterWrapper的接口。因此,依賴性得到了控制。此外,單元測試中的文件交互是一大痛苦。不惜任何代價避免它。數據庫交互也是如此。其實與外界的所有交互應存根/單元測試嘲笑。

美麗的是,SOLID設計和可測性齊頭並進。好的設計意味着可測試的代碼。如果你發現很難測試一些代碼,它通常表明有在你的設計中的缺陷。