深入浅出裸测之道---单元测试的单元化
原文
三层架构之解耦和单元测试

依赖注入DI很大程度的帮助测试单元化。这对层与层之间的依赖关系,几乎是真理。

如对数据读写的依赖关系,用IRepository替换之后,所有用到IRepository的类,如Serivce这一层的ExamService,在测试时,只需要传入一个Mock的IRepository类,就不需要使用真实的数据库对它测试了.

我们的另外一层Controller也用到Service这一层,同样我为Service这一层的实现也提出一个接口IExamService,在Controller的构造器中传入IExamService的Mock类。因此,很容易的让测试关注于Controller本身的行为和功能。甚至可以在ExamService类实现之前,我们就可以测试和实现Controller类。这是依赖注入的优势。

这一整套分层，解耦和测试我们已经实现了,并形成一个规范的过程和成形的框架。现在已经简单到按部就班,就能轻松完成,甚至后期都可以考虑自动生成这部分代码。但这部分现在不是本文的重点。
业务域的简单案例---构造器赋值

当我们的注意力转移到业务域时，情景有了悄悄的改变。业务域中,类与类之间有更多更复杂的依赖关系。相比之下，三层之间反而简单。

这里,把我正在做的考试（Exam）类做一个简单的背景介绍。考试，对于身经百战的我们应该不陌生了，让我们好好分析,看看熟悉身影的陌生之面。另外,我这里考试更多是拿社会化考试作分析目标。

一个考试有三个很重要的要素:考试代码（考试定义）;考区（北京考区,湖南考区）；考试日期。这三个要素,唯一标识一个考试,也就是说,同一个考区,同一个考试定义在同日期,我就认为是同一个考试。很简单的逻辑,为了体现这个逻辑,我把这三个要素,放在考试类的构造器中。为什么?任何一个要素的缺失,考试对象的存在都没有任何含义，所以一开始构造的时候，就要传入。从另一个角度,考区+考试定义+日期是考试的业务ID,是唯一标识，必须贯穿于业务对象的始终。

看代码:

 public class Exam
  {
  public Exam(District district, ExamDef exam_def, Date date)
  {
  District = district;
  ExamDef = exam_def;
  Date = date;
  }
  }

通过构造器,从外部传入三个对象后,把它们赋给考试的三不属性,而这三个属性是只读, Private是为了给nHibernate和构造器使用的。为什么?如前所说他们是业务动,在创建之后,再修改没有任何含义。

看代码:

public class Exam
  {
  public Exam(District district, ExamDef exam_def, Date date)
  {
  District = district;
  ExamDef = exam_def;
  Date = date;
  }
  public virtual ExamDef ExamDef { get; private set; }
  public virtual District District { get; private set; }
  public virtual Date Date { get;private set; }
  }


 

传统nUnit测试示例

好了,背景已经足够了。让我们来针对这部分功能进行测试。喂，等等，我们……现在有功能吗?有！我测试的描述就是,

  当从构造器链构造考试类时,三个属性应该要赋相应的值。

是的,足够简单使我们一目了然,也足够复杂,我们需要用测试来保障它的功能。 1. 保证它被运行---覆盖测试；2. 保证它是按我的设计进行的---行为测试。

看代码:

[TestFixture]
  public class when_create_an_exam
  {
  [Test]
  public void it_should_assign_parameters_to_properties()
  {
  //Arrange
  var stub_exam_def = new ExamDef("98");
  var stub_district = new District("01");
  var stub_date = new Date(2011, 1, 1);

  //Action
  var subject = new Exam(stub_district, stub_exam_def, stub_date);

  //Assert
  Assert.AreEqual(stub_district,subject.District);
  Assert.AreEqual(stub_exam_def,subject.ExamDef);
  Assert.AreEqual(stub_date,subject.Date);
  }
  }



引入三个中间变量和另外三个类的定义我就不在这罗嗦了。我的命名方式也曾为人病诟，也不在这辩解。只看实质内容：分别创建三个类的实例,用于测试,至于这三个类的具体内容,我其实并不关心。所以用个词Stub来表示我的不关心。DDD的核心理念之一：名符其实。最后,我的断言只判断属性的值是否与构造器传入值相符。OK,完成!
坏味道？---重构的提出

过一段时,间。我们再回头看看这段测试,会有些小小的不舒服。特别,我们还有更多的类有类似的构造器赋值功能,还有更多更复杂的功能等着我们去测试，我们在做商业软件，不是吗?随着类似的测试更得越多。这些小小的不舒服会越积越大。

这面的测试有什么问题?

1. 测试有三部分:建立测试环境；调用被测功能,(测试的本体)；断言。上面的代码,我甚至都已经刻意用注释分离出了这么三块,但仍不是语法级别的分离。

2. 对第三方的类依赖较为严重,这是本文的重点---单元测试单元化。对Exam类来说ExamDef, District都是插足的第三者。

3. 测试代码太多,被测的实际上只有三行，虽然这不是原则性的问题,但是本着更好，更快，更强的精神，这个问题也是值得解决的。

好了，你提出的问题已经太多了，我没办法一下子解决。3个还多？是的，我们的口号是“只要一个好”。
MSpec的引入--- AAA语法

言归正传,让我们本着选代和重构的原则来把这些问题一个一个解决。是的,测试也需要重构,测试代码还有bug呢?一点不奇怪。你没碰到过?噢，因为你根本不写测试代码。

关于测试的三段式,我曾经看过有人确实在nUnit的框架下一步一步重构,形成良好了测试框架。这里我就不这么麻烦了,直接上工具MSpec！测试的三段式，有个说法，叫AAA语法，分别是Arrange，Action，Assert。3A级语法，多酷!

而MSpec用了自己的名词，分别是Establish, Because, It。看看下