C# stub 。每个可测试对象的接口(interface)？

Question

关于“如何对类进行 stub 以便控制 SUT 中发生的事情”，我看到了多个答案。

他们说一件事:

Create an interface and inject that interface using dependency injection and create a stub using that same interface that you then inject into the SUT.

但是，我在以前的工作场所学到的东西:

If you unit test, you test all classes/functionality.

这是否意味着您必须为每个具有特定功能布局的类创建一个接口(interface)？

这意味着类/文件的数量将增加一倍。

如以下示例所示，这是“要走的路”还是我在单元测试过程中遗漏了什么？

注意事项:我正在使用 VS2012 Express。这意味着没有“Faker”框架。我正在使用“标准”VS2012 单元测试框架。

作为一个非常非常简单的示例，它允许我对传递给 SUT 的每个接口(interface)进行 stub 。

IFoo.cs

public interface IFoo
{
    string GetName();
}

Foo.cs

public class Foo : IFoo
{
    public string GetName()
    {
        return "logic goes here";
    }
}

IBar.cs:

public interface IBar : IFoo
{
    IFoo GetFoo();
}

条形图:

public class Bar : IBar
{
    public string GetName()
    {
        return "logic goes here";
    }

    public IFoo GetFoo()
    {
        return null; // some instance of IFoo
    }
}

IBaz.cs:

public interface IBaz
{
    IBar GetBar();
}

Baz.cs:

public class Baz
{
    public IBar GetBar()
    {
        return null; // some instance of IBar
    }
}

Answer 1

在我看来，你不应该仅仅为了单元测试的目的而创建接口(interface)。如果您开始添加代码抽象来取悦工具，那么它们不会帮助您提高工作效率。理想情况下，您编写的代码应该服务于特定的业务目的/需求——直接或间接地使代码库更易于维护或发展。

接口(interface)有时会这样做，但肯定不会总是这样。我发现为组件提供接口(interface)通常是一件好事，但尽量避免为内部类使用接口(interface)(即只在给定项目内部使用的代码，无论类型是否声明为 public)。这是因为一个组件(例如，一组一起工作以解决某些特定问题的类)代表了一个更大的概念(例如记录器或调度程序)，这是我可能希望在测试时替换或 stub 的东西.

解决方案(向 Robert 致敬，因为他在评论中排名第一)是使用模拟框架在运行时生成兼容的替换类型。然后，模拟框架允许您验证被测试的类是否与替代的虚拟对象正确交互。如前所述，最小起订量是一个时髦的选择。 Rhino.Mocks 和 NMock 是另外两个流行的框架。 Typemock Isolator Hook 到分析器中，是更强大的选项之一(允许您甚至替换非虚拟私有(private)成员)，但它是一个商业工具。

为应该进行多少单元测试制定规则是没有用的。这取决于您正在开发什么以及您的目标是什么 - 如果正确性总是胜过上市时间并且成本不是一个因素，那么单元测试一切都很棒。大多数人就没那么幸运了，他们将不得不妥协以达到合理的测试覆盖率水平。您应该测试多少还可能取决于团队的整体技能水平、预期的生命周期和正在编写的代码的重用性等。