.NET Core TDD 前传: 编写易于测试的代码 -- 依赖项

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

第1篇: 讲述了如何创造"缝". "缝"(seam)是需要知道的概念.

第2篇, 避免在构建对象时写出不易测试的代码.

本文是第3篇, 讲述依赖项和迪米特法则.

还是使用建造汽车的例子. 生产汽车的时候需要轮胎, 组装时需要什么型号的轮胎, 就请求该型号的轮胎, 然后相关人员会从库房把该型号的轮胎送到产线用于组装.

我相信很少有汽车厂会这样做: 生产汽车时, 汽车组装工拿着库房的钥匙, 自己去库房从各种各样的轮胎中找所需要的型号..

这就是违反迪米特法则的一个例子.

迪米特法则大概的意思是: "只访问你自己创建的对象, 或者作为参数传给你的对象. 不要通过其它对象间接的访问对象"

用一句话归纳迪米特法则就是: " 只与直系朋友交谈, 不要和陌生人交谈 ".

注意: 迪米特法则其实并不算严格的法则, 它只是一个非常有益的指导性原则.

用代码形容上面的例子就是:

这违反了迪米特法则, 导致了以下问题:

造成了BenzCar和Warehouse以及MichelinTire之间的 紧耦合 , 而实际上BenzCar只需要MichelinTire.
测试时, 设置会很麻烦 . 代码里Warehouse是直系朋友, MichelinTire是陌生人. 我们需要为Warehouse和MichelinTire同时设置测试替身.
真正需要的依赖项没有明确在构造函数里定义 . 这里Warehouse相当于是一个容器, 测试时, 我们可能会不知道要为Warehouse里的哪个东西做测试替身.

下列写法可能意味着您的代码违反了迪米特法则:

代码里有这样的调用: " warehouse.getTire.getMichelinTire ", 有一连串的点" . ". 但是有时候这样做是可以的, 例如流畅(fluent)形式的建造者模式就可以, 因为fluent接口通常会返回对象本身, 然后再去使用该对象.
依赖于容器 . 例如把 IocContainer作为依赖注入使用.
依赖项的名称为XxxContext, XxxContainer, XxxEnvironment, XxxManager, XxxServiceLocator .
测试时需要创建返回mocks的mock对象 .
测试时的设置非常麻烦 .