单元测试 – 在做TDD时要嘲笑的对象

当创建方法时,应该将该方法中实例化的每个对象作为参数传递,以便这些对象可以在我们的单元测试中被嘲笑？

我们在工作上有很多方法,没有相关的单元测试和回顾写作测试;我们发现在这些方法中实例化了很多对象.

我们的一个选择是将我们当前的方法重构为更多的单元,如方法,并减少每种方法的责任数量.这可能是相当漫长的过程,但对于我们来说肯定是一个很大的好处.

你怎么看？应该将一个方法中实例化的所有对象作为参数传入？

也许不是所有的对象,但是你注入到你的单位的对象越多,你的分离关系就越好,所以我一定会建议你朝这个方向前进.

您不必将所有对象作为方法参数传递.通过构造函数注入将合作者注入到类中通常是一个更好的设计.这将保持您的界面清洁,而您的实施可以导入所需的协作者.

假设您的原始实现如下所示：

public class Foo
{
    public Ploeh DoStuff(Fnaah f)
    {
        var bar = new Bar();
        return bar.DoIt(f);
    }
}

这可以改为如下所示：

public class Foo
{
    private readonly IBar bar;

    public Foo(IBar bar)
    {
        this.bar = bar;
    }

    public Ploeh DoStuff(Fnaah f)
    {
        return this.bar.DoIt(f);
    }
}

请注意,我将Bar从Bar的实例更改为IBar的实例,从而将Foo与IBar的具体实现进行了分离.这样的重构往往会使您的单元测试更易于编写和维护,因为您现在可以独立地改变Foo和Bar的实现.