關於SOLID/TDD的問題

Question

多年來，我一直對TDD感興趣，但有一兩件事情沒有點擊。我非常肯定，這是大多數人在嘗試時常見的想法。 「這本書中的例子非常好，但是我的代碼比這個複雜得多，我從來沒有一個程序能夠完成一件事，它會調用另外三個程序，並且會調用其他三個程序，並且這些程序會從DB ... bla bla bla「。一段時間以來，我在SOLID上發現了一些視頻（任何人都被卡住了，認爲TDD會很棒，但是......然後......在SOLID上找到一些視頻，相信我）。每一點都變得稍微混亂一些，直到最後，所有事情都已經到位，包括我如何考慮測試代碼和TDD。

我當然有很多舊的代碼，這不是這樣寫的，但我對此很好，因爲我確實看到了它應該如何的更好的想法。每當我做任何事情時，我都可以把它拿出來，並且正確地做到這一點（即使這意味着要切除需要更新的方法的一小部分，給它一個自己的類，然後調用它。）

它有幾個問題，我想知道我也許能找到那個答案，或者是有沒有一個標準。

多少應進行測試？
我的假設是它的全部。很多我的函數將採用輸入參數，並運行一個存儲過程我的猜測如何測試，將有一組給定的輸入參數，被稱爲正確的存儲過程，參數是否正確。經常這將是顯而易見的（有時會有數字輸入將被轉換爲逗號分隔的字符串）。如果沒有別的，這個例子，雖然測試可能沒有那麼有價值，但將是文檔。

我該如何命名？
這是發展的老問題。如果該類被命名爲喜歡的方法是，UpdateEmployee，還是應該有一大堆的er類（EmployeeUpdater，EmplyeeGetter等）

如何IOC一般如何處理？
現在仍然沒有問題，我正在創建接口，實現，設置IOC等。 雖然我可以看到，但很快我會在IOC中使用頁面和頁面以及接口/類映射頁初始化方法，或者我會想象它分裂成部分，用一個方法調用一些其他方法，每個方法註冊類（通過命名空間或某物）。這是如何一般工作，或有更聰明管理方式？

Answer 1

我建議由羅伯特·Ç馬丁

在我看來，讀書清潔守則......

多少應進行測試？

多少和多好有很大的區別。

最終它是一個判斷呼叫和或簡單的成本/收益分析。 關鍵應用程序/代碼應該進行更徹底的測試。 工作純TDD意味着您的代碼將被高度測試 - 輕鬆覆蓋90％以上，但請記住測試質量和覆蓋率之間存在差異。您可能決定測試更多邊緣案例。

您可以通過一個測試用例獲得100％的覆蓋範圍，但它的實用性測試了一系列值，例如0,1，很多&的界限。

我該如何命名？

以Java爲例，查看標準的Java API文檔，看看它們是如何實現的。 參考清潔代碼，命名是和應該是困難的，也許重構，如果名稱不再適合。從Java的API的

1. 的FileFilter
2. DesktopManager的

   示例類

名稱應該很明顯的類/方法/變量做什麼。

參閱Kent Beck的簡單設計的四個原則（快速意圖）

如何IOC一般如何處理？

也許其他人可以在這一點上做更多的擴展，但是提到極限編程，不要爲了它而使用接口，但是當你需要它們的時候。如果你只有一個具體的實例，你可能不需要一個接口。在您真正需要它們時重構添加接口以遵循已知的設計模式。

https://www.martinfowler.com/articles/designDead.html