c# - 具有深层嵌套依赖关系的单元测试和依赖注入(inject)

Question

假设遗留类和方法结构如下所示

public class Foo
{
    public void Frob(int a, int b)
    {
        if (a == 1)
        {
            if (b == 1)
            {
                // does something
            }
            else
            {
                if (b == 2)
                {
                    Bar bar = new Bar();
                    bar.Blah(a, b);
                }
            }
        }
        else
        {
            // does something
        }
    }
}

public class Bar
{
    public void Blah(int a, int b)
    {
        if (a == 0)
        {
            // does something
        }
        else
        {
            if (b == 0)
            {
                // does something
            }
            else
            {
                Baz baz = new Baz();
                baz.Save(a, b);
            }
        }
    }
}

public class Baz
{
    public void Save(int a, int b)
    {
        // saves data to file, database, whatever
    }
}

然后假设管理层发布了一项模糊的任务，要求对我们所做的每件新事物执行单元测试，无论是添加的功能、修改的需求还是错误修复。

我可能坚持字面解释，但我认为“单元测试”这个词是有意义的。这并不意味着，例如，给定输入 1 和 2，只有将 1 和 2 保存到数据库时，Foo.Frob 的单元测试才应该成功。根据我读过的内容，我相信它最终意味着基于 1 和 2 的输入，Frob 调用了 Bar.Blah。 Bar.Blah 是否做了它应该做的不是我的当务之急。如果我关心测试整个过程，我相信还有另一个术语，对吗？功能测试？场景测试？任何。如果我太死板了，请纠正我!

暂时坚持我的严格解释，假设我想尝试使用依赖注入(inject)，其中一个好处是我可以模拟我的类，这样我就可以，例如，不将我的测试数据保存到数据库或文件或任何情况下。在这种情况下，Foo.Frob需要IBar，IBar需要IBaz，IBaz可能需要一个数据库。这些依赖要注入(inject)到哪里呢？进入Foo？还是Foo只需要IBar，然后Foo负责创建IBaz的实例？

当您进入这样的嵌套结构时，您可以很快看到可能需要多个依赖项。执行此类注入(inject)的首选或可接受的方法是什么？

Answer 1

让我们从您的最后一个问题开始。注入(inject)的依赖项在哪里:一种常见的方法是使用构造函数注入(inject)(如 described by Fowler )。所以 Foo 在构造函数中被注入(inject)了一个 IBar 。 IBar 的具体实现，Bar 又在其构造函数中注入(inject)了一个IBaz。最后，IBaz 实现 (Baz) 注入(inject)了一个 IDatabase(或其他)。如果您使用 DI 框架，例如 Castle Project ，您只需要求 DI 容器为您解析 Foo 的实例。然后它将使用您配置的任何内容来确定您正在使用的 IBar 的实现。如果它确定您的 IBar 实现是 Bar，它将确定您使用的是哪个 IBaz 实现，等等。

这种方法为您提供的是，您可以单独测试每个具体实现，并检查它是否正确调用(模拟)抽象。

要评论您对过于死板等问题的担忧，我唯一能说的是，在我看来，您选择了正确的道路。也就是说，当实现所有这些测试的实际成本对他们来说变得显而易见时，管理层可能会感到惊讶。

希望这对您有所帮助。