unit-testing - 由于编写可测试代码而导致工厂过多

Question

我正在尝试编写易于测试的代码。这导致我避免直接​​调用 new Class1() 。相反，我通常创建一个接口(interface)，一个简单的工厂，其中包含一个返回该接口(interface)的 GetObject() 方法。

效果很好。我发现的问题是太多的工厂除了调用 new Class1() (或它们负责创建的任何类/接口(interface))之外基本上没有任何作用。我认为拥有可测试代码并不是一个很大的代价，但仍然...是否有人使用更好的方法并且仍然实现能够在测试时注入(inject) Class1 的不同实现的目标？

我知道我可以将 Class1 实现公开为属性并在运行时使用默认值，但这意味着我仅限于一个实例，而在许多情况下，我希望每次需要 Class1 时都创建一个新实例。

编辑:
我确实使用 IoC，这确实有帮助。尽管如此，我通常最终会在 IoC 配置中将工厂作为依赖项。我的 GetObject 方法通常调用 IoC.Resolve 之类的方法。我更喜欢将 IoC 依赖项隔离在工厂中，而不是直接隔离在包含业务逻辑的域类中。

Answer 1

有许多框架可以帮助实现这一目标。该技术称为控制反转。 .NET 世界中的示例:

• Spring.NET
• StructureMap
• Castle Windsor

所有这些框架的共同点是能够将组件(类)之间的绑定(bind)外部化为配置，该配置要么表示为配置文件(即 XML 中)，要么表示为“引导”代码。它们能够自动将依赖项注入(inject)到实例中，并为您解决类实例化和配置的问题。基本上，您可以将此任务留给 IoC 容器并停止创建自定义工厂类。

SO 上的相关资源标记为 ioc-container .

Martin Fowler 有一个 article描述 IoC 和实现技术，例如依赖注入(inject)和服务定位器。