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

前端之家收集整理的这篇文章主要介绍了单元测试 – 在做TDD时要嘲笑的对象前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
当创建方法时,应该将该方法中实例化的每个对象作为参数传递,以便这些对象可以在我们的单元测试中被嘲笑? @H_502_1@我们在工作上有很多方法,没有相关的单元测试和回顾写作测试;我们发现在这些方法中实例化了很多对象.

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

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

也许不是所有的对象,但是你注入到你的单位的对象越多,你的分离关系就越好,所以我一定会建议你朝这个方向前进. @H_502_1@您不必将所有对象作为方法参数传递.通过构造函数注入将合作者注入到类中通常是一个更好的设计.这将保持您的界面清洁,而您的实施可以导入所需的协作者.

@H_502_1@假设您的原始实现如下所示:

public class Foo
{
    public Ploeh DoStuff(Fnaah f)
    {
        var bar = new Bar();
        return bar.DoIt(f);
    }
}
@H_502_1@这可以改为如下所示:

public class Foo
{
    private readonly IBar bar;

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

    public Ploeh DoStuff(Fnaah f)
    {
        return this.bar.DoIt(f);
    }
}
@H_502_1@请注意,我将Bar从Bar的实例更改为IBar的实例,从而将Foo与IBar的具体实现进行了分离.这样的重构往往会使您的单元测试更易于编写和维护,因为您现在可以独立地改变Foo和Bar的实现.

猜你在找的设计模式相关文章