单元测试意识与软件质量

单元测试意识与软件质量

单元测试是和开发人员最密切相关的测试类型。它通常由开发人员编写和执行。由于单元测试通常发生在错误产生之后不久，因此通过单元测试发现错误然后进行修正的代价通常比较小。单元测试是如此重要，以至于一些极限编程爱好者主张任何未经测试的代码都应该被自动删除。

且不谈极限编程或TDD(测试驱动的开发)，我们都知道，bug越早发现越好;发现产品中存在的问题越早，开发费用就越低，产品质量就越高，软件发布后维护费用就越低。一个bug被隐藏的时间的越长，修复这个bug的代价就越大。最后才修改一个bug的代价可能是在bug产生时修改它的代价的10倍! 那么开发人员如何把bug消灭在最初的时候? 这就要依靠单元测试，依靠开发人员的编程习惯、质量意识(单元测试意识)和测试方法。下面分别对这几点说明：

1. 编程习惯：

实际上，程序员每写一行代码，每次修改已经存在的代码，无论修改有多微小，都有可能引入bug。而一个具有良好编程习惯的程序员写的代码bug数量明显少于编程习惯不好的程序员。优秀的程序员只是因为习惯。例如平常的编程规范的遵循，代码逻辑的清晰程度，边界条件的判断和异常处理，析构函数，Dispose方法的实现，函数的独立性，实现方法的效率等，都和程序员的习惯和专业素质有关。良好的编程习惯能尽量保证在一开始写程序时就避免bug的发生。(Careful programmers test early and test often.)

2. 单元测试意识：

微软企业方法是以测试为核心的，微软面试时经常会问一个开发人员，你写这段代码的时候，如何去判断你的代码是没有问题的呢?你会如何来测试它呢?也就是开发人员写代码的时候一定要有质量意识和测试意识，要懂得如何进行单元测试来确保自己的代码的可靠性。而不是没有测试意思和质量意识，一路酣畅淋漓的 写下去，根本不做单元测试，非常自信的认为自己的每行代码都是经典，其实自己都不知道写的代码是否正确，底层代码可靠性不得而知，上层的代码还在不断开发，最后在集成测试或者deadline时候才开始紧张，那就太晚了。平时就应该有良好的质量意识和测试意识，每个底层函数都要进行单元测试，保证可靠性然后入库。平时保持适当的紧张状态，到deadline的时候就不会紧张，因为每个底层函数都测试过，可靠性有保证。常做测试，早做测试，在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。

3. 测试方法：

除了以上两点以为，测试方法也是直接影响单元测试质量和软件质量的。我们知道，单元测试的覆盖种类有语句覆盖、判定分支覆盖、条件覆盖(条件一一覆盖，条件组合覆盖)、路径覆盖等，好的单元测试，应该覆盖所有代码路径和错误处理路径，要达到一定的覆盖率(Thorough)。尽量利用自动化单元测试工具以提高效率，例如JUnit，NUnit等等，自动化工具也有利于每日构建等行为;单元测试代码必须和代码一起入库和维护;以后当出现代码更改时候可以方便的自动进行回归测试;所以好的单元测试，必须是自动的(Automatic)，可重复的(Repeatable)。最后一点是单元测试的独立性(Independent)， 单元测试的运行/通过/失败不依赖于别的测试。

良好的单元测试策略给我们增强了对程序的信心，减少了bug的产生及bug的潜伏期。降低修改bug的代价。单元测试不会是项目开发周期的某一个生命周期，它贯穿于项目的整个生命周期，是一个非常重要的日常开发活动。

在极限编程中，测试驱动开发已经被证明是一种有效提高软件质量的方法。在测试驱动的开发方式中，软件工程师在编写功能代码之前首先编写测试代码，这样能从最开始保证程序代码的正确性，并且能够在程序的每次演进时进行自动的回归测试。