高效单体测试

高效单体测试
Tim Burns

心细的程序员早测试并频繁测试。

 

       单体测试。是不是我们会忽略一些让人讨厌的需求？我如果告诉你我们要从单体测试开始会如何？你也许会问，“我如何测试那些还没有写出来的代码啊？”我会回答，“单体测试就是用来确定你将要写的代码。”
 
       在提到单体测试的时候很多程序员会变得紧张。我猜想他们可能会想着列出了每个方法并标有期望值和通过/失败日期的大表格。我会把这种的单体测试留给那些为取得美国食品药品局审批而努力的家伙。这很重要，但和大部分的编程项目无关。

 

       单体测试会促进你所写的代码。某种意义上，它就是一个提醒你 “这部分代码干什么？”的小设计文档，或者是用面向对象的编程语言问“这些对象干什么？”。

 

       构建单体测试的主要问题是范围。如果范围太窄，测试将微不足道的，这些对象也可能通过测试，但是就会缺少它们之间的交互。显然，对象的交互是面向对象设计的核心。

 

       同样，如果范围太泛，很有可能不是所有新代码的每个组件都会被测到。程序员也只能被迫随机测测，这可不是有效的测试策略。

 

       我喜欢从需求文档中描叙的某个功能开始，并进行分解直至到不需要单体测试的方法。这样，测试就根据主要功能分组并包括待测功能所需的尽可能多地单体测试。

你如何知道一个方法不需要单体测试？首先，它是否可以通过检查测试？如果代码简单到开发人员一眼就可以确认其正确性，那它就不需要单体测试。开发人员应该会知道这种情况。

 

       单体测试通常在方法级别上定义，窍门就是在不能通过检查验证的方法上进行单体测试。通常涉及若干个对象的方法属于这种情况。能够隔离对象簇（Clusters of Objects）的单体测试则是“一箭双雕”。因为它们不仅可以测试失败点，还可以确认出代码相互关联的部分。但人们重看代码时会利用单体测试来发现哪些对象是关联的，哪些对象组成了对象簇。因此，单体测试可以为以后的开发人员隔离出对象簇。

 

        另外一个良好的试金石是看代码是否抛出错误或捕捉错误。如果在一个方法内进行了错误处理，那么这个方法就有可能失败。通常，任何可能失败的方法都是进行单体测试的好的目标，因为如果它在某时失败，单体测试就会在那帮助你修复它。

 

       不在所有方法上实施单体测试的风险就是可能覆盖不完整。不能仅仅因为我们没有显式地测试所有的方法就意味着那些方法可以不经过测试。程序员必须意识到他们的单体测试在可以覆盖所有代码的基本功能性需求的时候。心细的程序员会认识到当他们确认其单体测试可以覆盖组成应用的每个对象簇的时候就完整了。

 

原文链接： http://www.acm.org/ubiquity/views/t_burns_1.html