让软件测试也可以变得有趣的措施(2)

　　刚开始编写单元测试时很容易恢心。最佳的入手方式就是为新代码创建单元测试。(尽管为现有代码创建单元测试比较困难，但并非无法实现)。首先从新代码着手，待您习惯了整个过程以后，再针对现有代码创建测试程序。

　　如上文所述，应该首先编写单元测试，然后再编写这些单元测试要测试的代码。如何为尚不存在的代码编写测试呢?问得非常好。掌握这一方法需要 90% 的思维加 10% 的技术。我的意思是，您只需假定您正在为其编写测试的类已经存在。接下来的任务就是编写测试。起初会犯很多语法错误，但您先别管它。这一步您要做的就是定义该类要实现的接口。下一步就是运行您的单元测试，修正语法错误(即，编写一个类，使它实现您的测试刚定义的接口)，并再次运行测试。重复这一过程，每次仅编写修正故障的代码。运行测试，直到测试全部通过为止。一旦通过全部单元测试，代码也就完成了。

　　一般而言，类的每个公共方法都应有一个单元测试。但是，功能简单的方法(例如，getter 方法和 setter 方法)不需要单元测试，除非它们以某种特别的方式进行获取和设置。应该遵循下面这条很好的原则：即只要您认为有必要对代码中的某个行为加注，就编写一个单元测试。如果您像其他许多程序员一样不喜欢为代码加注，则单元测试是记录代码行为的一种方法。

　　将单元测试与被测试的相关类放在同一个包内。这种组织方式使每个单元测试都能访问被测试类中带有 package 或 protected 访问修饰符的方法和引用变量。

　　在单元测试中避免使用域对象。域对象是特定于某个应用程序的对象。例如，一个电子表格应用程序可能包含一个注册对象;这个注册对象就是一个域对象。如果您有一个已知这些域对象的类，则在测试中完全可以使用这些对象。但是如果您有一个根本不使用这些域对象的类，在测试中就不要将这些对象联系到该类上。应该避免这种情形完全是因为代码重用。为某一项目创建的类经常要用于其他项目。重用这些类可能很简单。但是，如果对重用类的测试中用到了另一个项目的域对象，则使测试能够正常运行这一工作就会相当耗时。通常情况下，这个测试将被删除或重写。

　　这些机制为您提供很好的帮助，但是如果您不运行这些测试，一套综合的单元测试就变得一文不值。尽早运行测试通常使您在任何时候都对代码充满信心。您将随着项目进展不断添加功能。运行这些测试将会通知您刚刚实现的新功能是否对系统造成了破坏。

　　在您掌握了编写单元测试的技巧之后，我们再来看看现有代码。为现有代码编写测试可能是个挑战。不要为测试而测试。当您发现有必要对一个未经很好测试(或者根本就没有测试)的类进行修改时，请“随时”编写测试。现在是添加测试的时候了。像往常那样，该类的单元测试应该捕获其每个方法的功能。找出应该进行哪些测试的最容易的方法之一是：查看现有代码中的注释。任何注释都应在单元测试内捕获。将位于方法开头、说明该方法所起作用的注释块翻译为单元测试。

　　如何编写功能测试

　　尽管功能测试很重要，但它却没有受到足够的重视。多数项目都有单独的一个组来做功能测试。通常有一大群人不断地与系统交互，以确定系统是否正确工作。这种观念和设置专门的功能测试小组的做法很不明智。

　　对功能测试的处理与对单元测试的处理不应该有太大的区别。只要您编写的代码用来产生要求用户与之交互的组件(如对话框)，就要编写测试，但实际上编写测试要在编写代码之前进行。请与用户一起编写获取用户需求的功能测试。无论何时开始一项新任务，都要在功能测试框架中描述此任务。您的开发工作将继续向前发展，当添加新代码时，请执行单元测试。当所有的单元测试都结束以后，运行最初的功能测试，看看它是否能够通过，或者是否需要修改。

　　从理论上讲，功能测试小组的概念该消失了。开发人员应与用户共同编写功能测试。在对系统所做的一系列功能测试结束之后，开发组中负责功能测试的成员就应该用初始测试的各种变化形式来轰击系统。

　　单元测试与功能测试的界限

　　通常单元测试与功能测试之间并没有明确的界限。老实说，有时我也不清楚这个界限在什么位置。在编写单元测试时，我根据以下原则来确定当前编写的单元测试实际上是否是功能测试：

　　如果单元测试跨越类边界，则它就可能是功能测试。

　　如果单元测试变得很复杂，则它可能是功能测试。

　　如果单元测试很脆弱(也就是说，虽然它是一个有效测试，但它必须不断改变以处理不同的用户组合)，则它可能是功能测试。

　　如果编写单元测试比编写其所测试的代码更难，则它可能是功能测试。

　　请注意“它可能是功能测试”这一措辞。本文无法提供硬性而快速的规则。单元测试与功能测试中之间有一个界限，但界限的具体位置要由您来确定。您用单元测试用得越熟练，某个特定测试是单元测试还是功能测试的界限就越明显。

　　小结

　　单元测试是从开发人员的角度出发编写的，并且关注的是所测试的类的特定方法。当编写单元测试时，请使用以下这些原则：

　　首先编写单元测试，然后再编写要测试的类代码

　　在单元测试中捕获代码注释。

　　测试所有执行“令人感兴趣的”功能(即，不是 getter 和 setter，除非它们以某种独特的方式执行获取和设置操作)的公共方法。

　　将每个测试实例与它要测试的类放在同一个包内，以获得对包成员和保护成员的访问权。

　　避免在单元测试中使用特定于域的对象。

　　功能测试是从用户的角度出发编写的，并且关注用户感兴趣的系统行为。找一个优秀的功能测试框架，或者开发一个测试框架，并使用这些功能测试识别用户的真实需求。这样，功能测试人员即可获得一种自动化工具以及使用这一工具的着手点。

　　使单元测试和功能测试成为您开发过程中的中心环节。如果您这样做了，您将对系统的运行及扩展充满信心。如果您没有这样做，您对系统就没有十足的把握。测试可能不那么有趣，但是在开发过程中进行单元测试和功能测试使开发变得相当有趣。

原文转自：http://www.ltesting.net