Objective-C中的TDD：属性/构造函数注入还是方法混合？

Question

自从我开始使用TDD以来，我一直坚信，这是一种很好的方式来编写符合正确模式的代码，而不会强迫我做出设计决定。 我发现这在80％的情况下是正确的，但是当涉及到测试某些特定的对象时出现问题，这些对象出于某种原因在实现中包装并隐藏了一个对象。

给你举个例子，让我们觉得MyLocationManager使用对象赋予一个通用的接口，我的对象，以及NSLocationManager内套。 当我想测试这样一个对象时，我必须提供一个模拟NSLocationManager。

我当然有属性/构造函数注入方法，但这意味着添加一个属性或构造函数参数，我只想隐藏其他对象的对象：我创建了MyLocationManager以包装并隐藏NSLocationManager，为什么我应该公开一个属性只是为了测试它？

我已经找到一种方法，这是非常简单的方法来调酒NSLocationManager的方法，这样我就可以交换的实际实施情况，模拟一个方法，但这似乎相当不干净，我不知道它是多么安全。

据我所知，Demeter Law的违规行为可能不会公开财产构造函数，但另一方面，我认为在objective-c中，这种模式的一些灵活性是可以接受的。

所以我的问题是，应该有什么办法我没有清楚地看到要采用属性/构造函数注入，还是方法swizzling是一种常用的做法？

是否有任何其他技术适用于此方案，我应该更好地使用？

脚注： 即使包装网络代码和类的对象（如NSUrlSession），此问题也是如此。

Answer 1

经过很长时间的测试驱动开发经验，我发现这个老问题很简单。 出于某种原因，我在想，属性注入和依赖注入避免掩盖某些东西。 我简直不想这个了。

在我原来的问题，从正确的答案的前面的场景现在的我是：

你不得不暴露NSLocationManager的依赖，也许提供了一个构造函数注入方法和便捷构造方法，以初始化位置管理器与NSLocationManager。
即使它是一个包装类，也不需要隐藏依赖关系，因为在发现自己需要调整某些方法的同时，您正在窃取对象的“内部”并且无需调整它测试接口，以不受控制的方式修改运行时行为。

如果你想旋转，提前调整，但它不是正确的选择。

Answer 2

那么，在某一时刻，测试设置可能比要测试的代码更复杂，所以人们可能会记得，测试是为了什么而发明的。

我认为一个实用的方法是，只需在包含单独类继续的单独头文件中公开属性。