现在的位置: 首页 > 综合 > 正文

我的测试生活感悟2 – Art Of Unit Testing

2011年07月14日 ⁄ 综合 ⁄ 共 903字 ⁄ 字号 评论关闭
今天把《Art Of Unit Testing》的前四个章节读完了,作者以自己的亲身经历,使用简洁清晰的语言,为我们展现了单元测试的艺术。
  1. 怎么定义一个好的测试案例呢?好的测试案例应该是在N年后还能运行良好并易于维护的。
  2. TOOD - Testabled Object-Oriended Design。作者也提到了这个颇有争议的问题,许多人认为,增加代码的可测性的同时,会使得代码变得更加丑陋。而作者不认为是这样,作者认为这样的修改 是另外一种面向对象,同样的也是优美的,这就是TOOD。
  3. 为了代码的可测性增加的一些代码,常常不希望编译到最后的产品中。可以有很多办法,比如用宏判断,如果使用的是.NE,还有一种办法,就是在相应的函数或类上面使用这个Attribute:[Conditional("DEBUG")]
  4. Action-Driven TestingResult-Driven Testing,两种不同的测试流派,一种检测行为本身,一种检查最后结果。不能说一定谁优谁劣,但作为单元测试,更多的应该是Action-Driven Testing,因为这样可以隔离一些其他外部的不稳定因素,当你的案例失败时,能够更加准备的定位问题所在。(事实上,集成测试就是Result-Driven Testing,一个很大的困惑就是集成测试案例失败了,通常是很难马上定位到原因的。)
  5. Stubs和Mocks的区别,这两个东西看起来几乎是一样的,事实上也确实很相似。但是,他们的区别也同样明显:Stubs不会导致案例失败,而Mocks会。换成我的理解就是,Stubs是一些假的东西,它能模拟一些我们想要的结果,而Mock呢,它就是一间谍(Test Spy),告诉我们被测代码做了些什么,于是,我们通过Mock对象来进行检查。
  6. One Mock Per Test,一个测试案例中,通常的模式是N个Stub对应1个Mock。如果一个测试案例有多于一个的Mock对象,说明你的案例感情不够专一。而一个测试案例,是可以有多个Stub对象的,他们共同协作模拟一些特定的虚拟场景,然后通过Mock对象,验证我们的被测对象是否对此做出了反应。

如果您觉得有用,请您告诉我,谢谢!

抱歉!评论已关闭.