遵循迪米特法则的单元测试
上一篇 /
下一篇 2012-07-05 15:15:51
/ 个人分类：单元测试
迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD。
迪米特法则可以简单说成：talk only to your immediate friends。 对于面向OOD来说，又被解释为下面几种方式：一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。
违反迪米特法则，会使类与外部的关系变的复杂，损害了代码的可测性。构造mock对象变得非常困难。如下面的例子：
该例子计算测试人员发现bug的得分。
class BugScore () { public： float GetTestScore (Idetec* idetec_handler){ float result = 0; Collegaue* p_clg_list = idetec_handler ->get_resource()->get_clg_list(); //省略其它代码 return result; } }; 测试代码如下，需要mock多个对象，增加测试代码复杂度。 |
//尝试测试GetTestScore函数 TEST( test_GetTestScore, BoundaryTesting ) { BugScore myBugScore; //需要mock idetec_handler //需要mock
resource_handler //需要mock clg_list EXPECT_TRUE(1.4 == myBugScore.GetTestScore
(idetec_mock)); } | |
拆分函数后的代码：
class BugScore() { public： float GetTestScore(Colleague* p_clg_list){ float result = 0; //…省略其它代码 return result; } }; |
测试代码只需Mock一次。
//尝试测试GetTestScore函数 TEST( test_GetTestScore, BoundaryTesting) { BugScore myBugScore; Mock_colleague mock; //省略mock的代码 EXPECT_TRUE(1.4 == myBugScore.GetTestScore
( &mock )); } |
收藏
举报
TAG:
