Objective-C中的TDD：屬性/構造函數注入還是方法混合？

Question

自從我開始使用TDD以來，我一直堅信，這是一種很好的方式來編寫符合正確模式的代碼，而不會強迫我做出設計決定。 我發現這在80％的情況下是正確的，但是當涉及到測試某些特定的對象時出現問題，這些對象出於某種原因在實現中包裝並隱藏了一個對象。

給你舉個例子，讓我們覺得MyLocationManager使用對象賦予一個通用的接口，我的對象，以及NSLocationManager內套。 當我想測試這樣一個對象時，我必須提供一個模擬NSLocationManager。

我當然有屬性/構造函數注入方法，但這意味着添加一個屬性或構造函數參數，我只想隱藏其他對象的對象：我創建了MyLocationManager以包裝並隱藏NSLocationManager，爲什麼我應該公開一個屬性只是爲了測試它？

我已經找到一種方法，這是非常簡單的方法來調酒NSLocationManager的方法，這樣我就可以交換的實際實施情況，模擬一個方法，但這似乎相當不乾淨，我不知道它是多麼安全。

據我所知，Demeter Law的違規行爲可能不會公開財產構造函數，但另一方面，我認爲在objective-c中，這種模式的一些靈活性是可以接受的。

所以我的問題是，應該有什麼辦法我沒有清楚地看到要採用屬性/構造函數注入，還是方法swizzling是一種常用的做法？

是否有任何其他技術適用於此方案，我應該更好地使用？

腳註： 即使包裝網絡代碼和類的對象（如NSUrlSession），此問題也是如此。

Answer 1

經過很長時間的測試驅動開發經驗，我發現這個老問題很簡單。 出於某種原因，我在想，屬性注入和依賴注入避免掩蓋某些東西。 我簡直不想這個了。

在我原來的問題，從正確的答案的前面的場景現在的我是：

你不得不暴露NSLocationManager的依賴，也許提供了一個構造函數注入方法和便捷構造方法，以初始化位置管理器與NSLocationManager。
即使它是一個包裝類，也不需要隱藏依賴關係，因爲在發現自己需要調整某些方法的同時，您正在竊取對象的「內部」並且無需調整它測試接口，以不受控制的方式修改運行時行爲。

如果你想旋轉，提前調整，但它不是正確的選擇。

Answer 2

那麼，在某一時刻，測試設置可能比要測試的代碼更復雜，所以人們可能會記得，測試是爲了什麼而發明的。

我認爲一個實用的方法是，只需在包含單獨類繼續的單獨頭文件中公開屬性。