这些机制为您提供很好的帮助，但是如果您不运行这些测试，一套综合的单元测试就变得一文不值。尽早运行测试通常使您在任何时候都对代码充满信心。您将随着项目进展不断添加功能。运行这些测试将会通知您刚刚实现的新功能是否对系统造成了破坏。
在您掌握了编写单元测试的技巧之后，我们再来看看现有代码。为现有代码编写测试可能是个挑战。不要为测试而测试。当您发现有必要对一个未经很好测试（或者根本就没有测试）的类进行修改时，请“随时”编写测试。现在是添加测试的时候了。像往常那样，该类的单元测试应该捕获其每个方法的功能。找出应该进行哪些测试的最容易的方法之一是：查看现有代码中的注释。任何注释都应在单元测试内捕获。将位于方法开头、说明该方法所起作用的注释块翻译为单元测试。
如何编写功能测试
尽管功能测试很重要，但它却没有受到足够的重视。多数项目都有单独的一个组来做功能测试。通常有一大群人不断地与系统交互，以确定系统是否正确工作。这种观念和设置专门的功能测试小组的做法很不明智。
对功能测试的处理与对单元测试的处理不应该有太大的区别。只要您编写的代码用来产生要求用户与之交互的组件（如对话框），就要编写测试，但实际上编写测试要在编写代码之前进行。请与用户一起编写获取用户需求的功能测试。无论何时开始一项新任务，都要在功能测试框架中描述此任务。您的开发工作将继续向前发展，当添加新代码时，请执行单元测试。当所有的单元测试都结束以后，运行最初的功能测试，看看它是否能够通过，或者是否需要修改。
从理论上讲，功能测试小组的概念该消失了。开发人员应与用户共同编写功能测试。在对系统所做的一系列功能测试结束之后，开发组中负责功能测试的成员就应该用初始测试的各种变化形式来轰击系统。
单元测试与功能测试的界限
通常单元测试与功能测试之间并没有明确的界限。老实说，有时我也不清楚这个界限在什么位置。在编写单元测试时，我根据以下原则来确定当前编写的单元测试实际上是否是功能测试：
如果单元测试跨越类边界，则它就可能是功能测试。
如果单元测试很脆弱（也就是说，虽然它是一个有效测试，但它必须不断改变以处理不同的用户组合），则它可能是功能测试。
如果编写单元测试比编写其所测试的代码更难，则它可能是功能测试。
请注意“它可能是功能测试”这一措辞。本文无法提供硬性而快速的规则。单元测试与功能测试中之间有一个界限，但界限的具体位置要由您来确定。您用单元测试用得越熟练，某个特定测试是单元测试还是功能测试的界限就越明显。
小结
单元测试是从开发人员的角度出发编写的，并且关注的是所测试的类的特定方法。当编写单元测试时，请使用以下这些原则：
首先编写单元测试，然后再编写要测试的类代码
在单元测试中捕获代码注释。
测试所有执行“令人感兴趣的”功能（即，不是 getter 和 setter，除非它们以某种独特的方式执行获取和设置操作）的公共方法。
将每个测试实例与它要测试的类放在同一个包内，以获得对包成员和保护成员的访问权。
避免在单元测试中使用特定于域的对象。
功能测试是从用户的角度出发编写的，并且关注用户感兴趣的系统行为。找一个优秀的功能测试框架，或者开发一个测试框架，并使用这些功能测试识别用户的真实需求。这样，功能测试人员即可获得一种自动化工具以及使用这一工具的着手点。
使单元测试和功能测试成为您开发过程中的中心环节。如果您这样做了，您将对系统的运行及扩展充满信心。如果您没有这样做，您对系统就没有十足的把握。测试可能不那么有趣，但是在开发过程中进行单元测试和功能测试使开发变得相当有趣。
文章来源于领测软件测试网 https://www.ltesting.net/
