单元测试 – 按合同设计,编写测试友好的代码,对象构建和依赖注入将所有最佳实践结合在一起

我一直试图找出编写测试友好代码的最佳实践,但更具体地说是与对象构造相关的实践.在蓝皮书中,我们发现我们应该在创建对象时强制执行不变量,以避免我们的实体,值对象等的损坏,考虑到这一点,Design By Contract似乎是避免我们的对象损坏的解决方案,但是当我们遵循这一点,我们最终可能会编写如下代码
class Car
{
   //Constructor
   public Car(Door door,Engine engine,Wheel wheel)
   {
      Contract.Requires(door).IsNotNull("Door is required");
      Contract.Requires(engine).IsNotNull("Engine is required");
      Contract.Requires(wheel).IsNotNull("Wheel is required");
      ....
   }
   ...
   public void StartEngine()
   {
      this.engine.Start();
   }
}

嗯,这看起来很好看吗?看来我们正在建立一个暴露所需合同的安全类,所以每次创建Car对象时我们都可以确定该对象是“有效的”.

现在让我们从测试驱动的角度来看这个例子.

我想构建测试友好的代码,但为了能够隔离测试我的Car对象,我需要为每个依赖创建一个模拟存根或一个虚拟对象,只是为了创建我的对象,即使我可能只是想测试仅使用其中一个依赖项的方法,如StartEngine方法.遵循Misko Hevery的测试哲学我想编写我的测试明确指出我不关心Door或Wheel对象只是将null引用传递给构造函数,但是因为我正在检查nulls,所以我不能这样做

这只是一小段代码,但是当您面对真正的应用程序时,编写测试会变得越来越难,因为您必须解决主题的依赖关系

Misko建议我们不要滥用代码中的空值检查(这与设计合同相矛盾),因为这样做,编写测试会变得很痛苦,作为替代方案,他认为编写更多的测试比“只有错误”更好.我们的代码是安全的,因为我们到处都有空检查“

你对此有何看法?
你会怎么做?
什么应该是最好的做法?

看看 test data builders的概念.

使用预配置数据创建构建器一次,必要时覆盖属性调用Build()以获取受测试系统的新实例.

或者您可以查看Enterprise Library的源代码.测试包含一个名为ArrangeActAssert的基类,它为BDD-ish测试提供了很好的支持.您可以在从AAA派生的类的Arrange方法中实现测试设置,并且只要您运行特定测试,就会调用它.

相关文章

适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题...
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结...
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容...