可测试性与过度设计？ [复制]答案

【问题标题】：Testability versus Over-Design? [duplicate]可测试性与过度设计？ [复制]
【发布时间】：2013-03-27 18:32:22
【问题描述】：

这是一位与我感兴趣的同事实际提出的情况：

public DoSomething()
{
    //Do Stuff
    var assembly = Assembly.LoadFrom("Path");
    //Do More Stuff
}

所以，为了模拟这个，你有两个选择

创建一个internal virtual 方法：

internal virtual IAssembly LoadAssembly(String path){...Load Here...}

或者，添加一个可以传入的新类

public class AssemblyLoader
{
    public virtual IAssembly LoadAssembly(String path){...Load here...}
}

这两个选项似乎都有问题，因为第一个似乎应该是私有方法，而第二个似乎是为简单的静态调用创建包装器的过度设计？

所以，我想我会把它带到社区。我正在寻找最实用的方法，同时保持 unit 可测试。

这类似于this SO question，但我真的想更深入地研究它。

【问题讨论】：

你不能实现依赖注入吗？如果您以这种方式构建它，它将保持可测试和可维护。虽然它会有点难以阅读。
更好的问题是，您在构造函数中放入了多少逻辑？如果您需要对构造函数进行单元测试，这听起来更像是代码异味。
投票支持第二个选项。它确实会产生开销，但并不大，而且它服务于“更大的目的”。它干净且易于理解，并且使用自动注册的 DI 容器，您甚至不必在单元测试之外再关心它。
@AlG，使用 Assembly.LoadFrom 作为示例不会使这个问题与 实际上试图处理 Assembly.LoadFrom 的问题重复。我>
@JustinPihony，您可能可以在Programmers.SE 上进行一些搜索，因为我相信那里有一些类似的主题，有不同的意见。我，一方面，会去依赖注入。你知道这句格言，“计算机科学中的所有问题都可以通过另一个抽象层次来解决……除了抽象层次太多的问题。”

标签： c# unit-testing tdd moq assembly.load

【解决方案1】：

这个问题太笼统了，很难回答。

一般来说，我认为你的问题是人为的。您认为为 3rd 方服务创建包装器是过度设计，但同时说此包装器是解决实际问题的方法。如果它解决了一个真正的问题，这听起来不像是过度设计，包装器实际上听起来像是好的设计。

当您需要在不受控制的代码上配置状态时，为 3rd 方服务创建包装器通常很明智。它没有你想象的那么难闻。事实上，我没有看到另一种方法来做到这一点。无论你如何分割它，无论你是使用一些 3rd 方库进行模拟，使用一些反射魔法，还是使用你有目的的解决方案，这一切都归结为包装真正的 3rd 方 api。

如果您的直觉仍然认为包装此外部 api 是过度设计，那么您可能需要重新构建您的问题。问问自己，应该测试这段代码吗？

【讨论】：

是的，我同意。我想问题出在通常我不会模拟静态方法的事实。但是，此方法对文件系统具有外部依赖性。对我来说真正的问题是，这可能应该是一个实例对象，这就是问题所在……为了可测试性，我必须包装一些东西，这就是我不喜欢它的原因。它只是为了可测试性而更改我的代码，但这只是由于第 3 方的糟糕设计......
@JustinPihony “但这只是由于第 3 方的糟糕设计”。是的，这正是你想从中抽象出来的东西。为了可测试性而更改代码不是是一件坏事。如果您关心测试，那么更改代码以支持它只是让您的代码根据您的要求“更正确”。

【解决方案2】：

这里很难一概而论，但是加载程序集前后的 cmets 表明 DoSomething 方法可能违反了 Single Responsibility Principle。也就是说，代码做了太多的事情。有很多方法可以编写代码，这样您就可以避免这种情况，您在问题中提到了其中两种。我想我会听从 Greg 的建议并在这里实施依赖注入。根据这个例子，我很难说什么是过度设计，什么不是过度设计。

【讨论】：